FB II COMPILER

How about defining a structure like so:

DIM RECORD MyGlobals
  DIM myVar$
  DIM myOtherVar%
etc..
DIM END RECORD.MyGlobals

And a pointer that will lead to it:

DIM gGlobalsPtr&

But don't create an instance of the struct in your globals file. Then, in the init stage of your app, create a new pointer for your structure:

gGlobalsPtr& = FN NewPtr _Clear(_MyGlobals+4)

Now you can setup all the values in the struct, and any include can get at then using the offset notation:

theVarIWant% = gGlobalsPtr&.myOtherVar%

This way the globals don't have to sit in the first 32k as per normal, and the definitions don't take up any room.

why the +4 in FN NEWPTR ??

Good Habit. A form of low-grade memory protection stolen from Copland. If you overwrite 1 or 2 bytes, your app won't crash, and you can also use it to check if something did go wrong somewhere, by the presence of non-zero in this area. Here is another Apple trick for records: Make the first field of the record a long to store a copy of the address of the record. You can set it up like this:

DIM RECORD Blah
 DIM ValidityCheck&
Ôetc..
DIM END RECORD Blah

DIM myBlah.Blah

myBlah.ValidityCheck& = @myBlah

Then any routine that gets passed a pointer to the struct can test it by saying:

LOCAL FN SimpleRoutine(PtrToRecord&)
  
  LONG IF PtrToRecord& <> PtrToRecord&.ValidityCheck&
    ' Bad pointer, wig-out now!
  XELSE
    ' 98 percent chance its good, continue...
  END IF
END FN

Then again, who of us ever passes a bogus pointer?