FB II Compiler

PG PRO

Debugging

Memory

System

Mathematics

Resources

Disk I/O

Windows

Controls

Menus

Mouse

Keyboard

Text

Fonts

Drawing

Sound

Clipboard

Printing

Communication

ASM

Made with FB

FB II COMPILER

Consider different handling of global variables


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.
Jamin

why the +4 in FN NEWPTR ??

Pete

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?
Jamin