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.MyGlobalsAnd 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& = @myBlahThen 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 FNThen again, who of us ever passes a bogus pointer?