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?