Chris wrote:

> Where did the '#' come from, and what does it mean? (It isn't listed as a
> shortcut in the FutureBasic Help window).

Many Toolbox routines need to know the address where some data is stored
(rather than simply knowing the contents of the data).  The way this is
typically implemented in FB is: (1) You create an FB variable (possibly
storing some data in it); (2) you specify the variable as a parameter
when you make the Toolbox call; and then (3) FB internally passes the
variable's _address_ to the Mac Toolbox.

But sometimes it's useful for you to pass an _arbitrary_ address to the
Toolbox routine--an address which may or may not be occupied by an FB
variable.  That's where the "#" syntax comes in.  When you pass a
long-integer expression to the Toolbox routine, and precede the
expression with "#", then FB evaluates the expression as an address, and
passes _that_ address to the Mac Toolbox.  Here's an example:  Suppose
we have an 8-byte variable called "rect" which happens to be located at
address 27505392.  Then suppose we do this:

  CALL SETRECT(rect, 10,10, 250, 350)

It turns out that SetRect likes an address as its first parameter, so FB
passes the number 27505392 (the address of rect) to the Toolbox.

But now suppose that you really want to pass some _other_ address to
SetRect: say the address that's 14 bytes inside some handle h&, rather
than the address of some FB variable.  You can do it like this:

  CALL SETRECT(#[h&]+14, 10, 10, 250, 350)

Because of the "#", FB knows that what follows should be interpreted as
a long integer expression.  It evaluates that expression (in this case,
the expression indicates some address in the "heap"), and it passes
that value to SetRect.  SetRect will then dutifully alter 8 bytes inside
that handle, rather than 8 bytes in some FB variable.

The "#" syntax doesn't work for all parameters in all Toolbox routines.
It only works for parameters where _both_ of these apply:
(a) the MacOS expects an address, and 
(b) FB (normally) expects a _variable_ (whose address
    FB extracts internally).

In such special cases, you're allowed to specify the Toolbox parameter
in either of the following ways:

<var>    (in this case, FB passes the address of <var> to the Toolbox)
#<expr&> (in this case, FB passes the value of <expr&> to the Toolbox)

In a few weird situations, it's convenient to keep your data in a
variable (suggesting the first of the 2 syntaxes above), but the FB
compiler just doesn't like the particular type of variable you're
using.  People get around this problem by using the second syntax, but
substituting the variable's address for <expr&>, like so:

  #@myVar

This has led some people to look at the "#" syntax as a kind of way to
"override type-checking" of parameter variables; but I think this is a
misleading way to look at it, because it can be used for other purposes,
and it can be used without variables at all (for example, you can pass
#_nil), and especially because the "#" won't even compile except in
certain parameters in certain Toolbox routines.

Since FB is not 100% consistent in the way it interprets Toolbox
parameters, sometimes it takes trial-and-error to figure out which
parameters will accept "#".  For example, in FB's implementation of
GETCATINFO, condition "(a)" is satisfied, but not condition "(b)".
So "#" can't be used in GETCATINFO.  But in other routines such as
SETRECT or (as you've discovered) BITTST, both "(a)" and "(b)" are
satisfied, so "#" works.

- Rick