Sorry your browser is not supported!

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):


and here's the plain DBPro equivalent:


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.

Well, couldn't you just (I mean, "just") program a sort of preprocessor which looks for such lines:
static varname (as vartype) (= value)
within functions and as consequence automatically renames them for this function by using the functionname as prefix?

For instance, this code



...would be changed to this:



This way you would not need to use more commands within your function, you would not need to write longer variable-names and the program would not be slower in any way (I guess). The only disadvantages are, that your compiletime would be a bit higher (depending on the programming language used for the preprocessor something between nothing and ~two seconds or so) and that this method is not totally save (Typing Test_myVar manually somewhere in the code would access the static variable from outside the function)... even though a possible solution for the preprocessor would be renaming all variables _containing_ the name, so "myVar" inside the function would be changed to "Test_MyVar" and all variable containing "myVar" outside the function would get a "main_"-prefix or so... however, could become quite complicated on this level. Still, is my basic idea actually right? Or did I misunderstand something?

Edit: I'm just wondering why my [*code*]-tag (without stars of course) doesn't work.... it always used to, am I doing something wrong?

[MOD EDIT - IanM]Yes, the last code tag didn't contain the leading slash.

How about this one? variable "a" will be all your concern and you can make it local or global doesnt matter.