---

This little library works around the No Static Local Variables issue with DBPro. Unfortunately, using this method, I've been unable to come up with a way to avoid having to declare the local variables prior to using them. Small price though. Also you might find the syntax a little cumbersome, but it works. It should also be fairly fast and is not too much of a drain on resources. I would still recommend using these sparingly. Finally, the limit is set by default to assign any given static local variable to about 100 functions. If you need more than this, it is relatively easy to change. There is really no need to go less than 100 functions.

There are three basic commands: Declare, Set, and Get:

Include files:
#INCLUDE "Local Variables.dba"
#INCLUDE "EDNA v2.dba"

Declaration/Initialization:
Declare_Local_Variable MyLocalVar

Set/store value:
MyLocalVar = Set_Variable MyLocalVar , 22.5 As_Local

Get/return value:
ReturnValue = Get_Variable MyLocalVar As_Local

The value stored/retrieved can be any Integer, DWord, or Float (and will also work for Boolean, Byte, and Words), but cannot store strings. Just be sure to retrieve the same data type as was stored, or you might have problems.

I tried to make this as Command-like as possible within the rules of DBPro. This is why the libraries are included; to help with thinking of these as commands instead of a DBPro library of functions. If you want, feel free to dive into the background code and have a look around.

Note: Requires IanM's Matrix1 Utilities.

---

I'm sorry to say that there's no need for all of that code for this kind of thing - it can be done more simply using vanilla DBPro.

Here's code using your system for incrementing a static variable (it appears to work, so I think I'm using your library correctly):
+ Code Snippet

#INCLUDE "Local Variables.dba"
#INCLUDE "EDNA v2.dba"

Declare_Local_Variable Initialization
Declare_Local_Variable CounterValue

for i = 1 to 10
   StaticsTest()
next

wait key

end

function StaticsTest()
   Initialized = Get_Variable Initialization As_Local
   If Not Initialized
      Initialization = Set_Variable Initialization , 1 As_Local

      Counter = Set_Variable CounterValue, 0 As_Local
   Endif

   Counter = Get_Variable CounterValue As_Local
   inc Counter
   CounterValue = Set_Variable CounterValue, Counter As_Local

   print "Counter = "; Counter
EndFunction

and here's the plain DBPro equivalent:
+ Code Snippet

for i = 1 to 10
   StaticsTest()
next

wait key

end

function StaticsTest()
   if StaticsTest_StaticInitialised = 0
      global StaticsTest_StaticInitialised  as integer = 1

      global StaticsTest_Counter as integer = 0
      global StaticsTest_Message as string = ""
   endif

   inc StaticsTest_Counter
   StaticsTest_Message = StaticsTest_Message + "."

   print "Counter = "; StaticsTest_Counter; " "; StaticsTest_Message
endfunction

The difference is that the DBPro global/static trick works with strings, UDTs and arrays too, not just numerics, it's type-safe, and it's fast.

I do like the way that you used function pointers as identifiers though.

---

Thanks for the feedback Ian. I personally am not all that hung up on using static local variables and would be more than happy to use global variables instead (pretty much the way you just did). What cannot really be done without using some form of static local variables library is using the same variable name within different functions. And the irony of all this is not lost on me - I get it: Type extra commands to avoid having to type extended variable names.

On the flip-side, I am really getting into documenting my code, even using variable and function dictionaries. Documenting a single static local variable is a heck of lot easier than documenting a different variable for each function. Again, the simple solution is to simply document the variable underscore extended name (i.e. _initialized: A variable extension used to indicate the variable is used to track the initialization of a function).

Finally, this was probably more an exercise in coding than anything else.


Ideally it would be great to be able to determine which function was called previous to the current function (behind the scenes). This can be done with a simple global variable and just store the Function ID at the start of each function:

LastFunctionCalled = CurrentFunctionCalled
CurrentFunctionCalled = Get PTR To This Function()

Or, if something like that could be handled behind the scenes in a dll, that would be useful for a variety of purposes (hint-hint, wink-wink). Mainly it would be extremely useful for error handling.