Silvain wrote:

> _resPurgeable = 5
> Often, i see _resPurgeable as _resPurgeable%  (note the %)
> Why ?

This is a peculiar FB syntax thing.  There are at least four completely
different meanings of the "%" symbol in FB, and this is one of them.

_resPurgeable% means: "2 raised to the power of _resPurgeable."  Where
_resPurgeable equals 5, _resPurgeable% equals 32.

The reason this is useful is that many predefined constants represent a
bit position that's used in some binary number.  If you have some
constant _myBitPos defined, then _myBitPos% represents: "the binary
number which has the bit in position _myBitPos set to 1, and all the
other bits set to 0."

> If i wanted to replace the constant with the numeral, should
> i use 5 or 5% ???

Either.  While _resPurgeable and _resPurgeable% have two completely
different values, 5 and 5% both mean 5.  In _most_ cases, a symbolic
constant and its literal equivalent are interchangeable, but this is an
exception.

To make things even more confusing, if you use a symbolic constant
following a "dot," then the "%" suffix means something else; namely
"short integer."  So:

_resPurgeable means 5
_resPurgeable% means 32

but:

myRecord.resPurgeable% means: "the short integer located 5 bytes past
the beginning of myRecord".  If "short-integer" is your default variable
type, then "myRecord.resPurgeable%" is exactly identical to
"myRecord.resPurgeable".

Note that you can also use the syntax _myConst% in situations where a
symbolic constant or literal integer is required.  So, while these all
represent the same value:

_myConst%
BIT(_myConst)
2 ^ _myConst

...only the first of the following will compile:

DIM z(_myConst%)      'will compile
DIM z(BIT(_myConst))  'won't compile
DIM z(2 ^ _myConst)   'won't compile

> Also, if more than one constant is used, can i really only replace the
> whole thing with just the total value ?
> 
> COMPILE 0, _pointerVars _appendRes _dimmedVarsOnly

Yes.  The compiler sums all the constants.  It gives the same result as
the expression "_pointerVars + _appendRes + _dimmedVarsOnly", but the
two forms are used in two different situations:

* You must _exclude_ the "+" symbol(s) in statement that require
  a symbolic constant or integer literal.
* You must _include_ the "+" symbol(s) in statements that _don't_
  require a symbolic constant or literal integer.

So, these will compile:

_myConst = _k4 _k5
DIM myArray%(_k1 _k2 _k3)

...but these won't:

_myConst = _k4 + _k5
DIM myArray%(_k1+_k2+_k3)
 
Also, these will compile:

myNumber% = _k1 + _k2
PRINT _k3 + _k4

...but these won't:

myNumber% = _k1  _k2
PRINT _k3  _k4

Finally, the "space means '+'" syntax won't work for symbolic constants
that have the "%" suffix, nor for literal integers.

This won't compile:
DIM myArray%(7  22)

This _will_ compile, but gives unpredictable results!
DIM myArray%(_k1% _k2%)

- Rick

p.s.  I would like to point out that Netscape "froze" after I had
_almost_ finished composing this reply but before I had saved it to
disk.  I was able to drop into MacsBug, search Netscape's heap space for
the buffer containing my near-complete message, write that chunk of
memory to disk, and then reconstruct the message.  I wonder how easy
that would have been on a Windows machine?