[futurebasic] Re: [FB] playing .wav sound files from FB (TAKE 3)

Message: < previous - next > : Reply : Subscribe : Cleanse
Home   : April 1999 : Group Archive : Group : All Groups

From: Rick Brown <rbrown@...>
Date: Thu, 01 Apr 1999 20:29:49 -0600
Michael Evans wrote:

> (I would be grateful for some feedback on the need for the strange use of a
> pseudo FSSpec (see '#specPtr& in 'FN PlayWaveUsingQuickTime(wFname$,
> srcWD%)' below. The FBII manual says just use a standard FSSpec
> [as in DIM myFSSpec.70], not a pointer to an FSSpec....
> {whine, whine, bitch, moan.....})

There are a number Toolbox functions/procedures in FB which have the following
characteristics for one or more of their parameters:
1. The Toolbox routine (internally) "wants" the parameter to be an address to a
data structure;
2. FB lets you specify a variable (rather than an address) in that parameter;
FB then passes the variable's address to the Toolbox routine, to satisfy the
Toolbox's need for an address.

Strangely, there's a subset of such routines which FB has chosen to implement
with this additional bizarre restriction:
3. The variable that you specify _must_ be a short integer variable--even if
the data structure "inside" the variable is supposed to be many bytes
in length(!)

This is why you often get the (completely misleading) error message, "Must be a
long integer variable."  This message is in error: it really should say, "Must
be a _short_ integer variable," because that is what FB is expecting you to put
there.  I don't know why they've never fixed this message.

There are two ways to handle this situation.  Let's say a certain Toolbox call
falls into this category and it wants the address to a 10-byte structure.  Your
first impulse is to pass a variable declared like this:

DIM myRec.10

But, in this hypothetical case, the variable must be a short integer, so the
compiler complains when you pass "myRec".  So one possible solution is to
declare it like this instead:

DIM myRec;10

In this case, "myRec" is actually and literally a 2-byte short-integer
variable, but it's followed by 8 bytes of "free" space into which you can put
whatever you want.  This makes the compiler happy; FB passes the address of
"myRec" to the Toolbox routine; the Toolbox routine doesn't know from short
integers; it just looks at the address as the beginning of a 10-byte buffer.

The other solution is to use the "#" syntax.  The "#" syntax can _only_ be used
in Toolbox parameters that satisfy conditions "1" and "2" above (with or
without "3").  When FB sees the "#", it stops looking for a variable in that
position, and instead looks for (any) long-integer expression.  It evaluates
the expression, and sends the result to the Toolbox routine.  The Toolbox
routine then uses that value as the "address" that it wants.

So to recap: For those parameters that satisfy conditions "1" and "2", the
Toolbox routine receives either:

* The address of an FB variable (when you specify that variable as the
parameter); or:
* An arbitrary long-integer value (when you specify a long-integer expression
preceded by "#")

In our example situation, you could do any of the following:

DIM myRec;10
CALL SOMETOOLBOX(myRec)  'Happy to have a short integer var

or:

DIM myRec.10
myRecPtr& = @myRec
CALL SOMETOOLBOX(#myRecPtr&)  'Any long int expression OK

or even:

DIM myRec.10
CALL SOMETOOLBOX(#@myRec)  '@myRec is a long int expression


Hope this helps.
- Rick