It means that you don’t want the variable to vanish when the current procedure ends, but that doesn’t necessarily mean you’re going to use it in any other procedures. Also, it may mean that you want to display the variable, even if it is only used in one or two procedures.
rather than have an easter egg hunt later on.
If you give your variables reasonably unique names, the View Search window makes the easter egg hunt pretty easy these days. I’ll admit it was a lot more difficult before View Search was available.
Personally, I don’t set up fileglobal variables in the .Initialize routine unless they are variables that need to be defined from the first instant the database is opened. If a variable is only going to be used in one or two procedures, I’ll just set it up there.
However, this is a personal stylistic preference, so I certainly won’t say your approach is wrong. But it’s not the approach I take.
But for clarification, regardless of the intended use, once you declare it as a file global, it sticks around until the file is closed, right? So if you create it in one location, you have to remember that and not create another with the same name later. I’ve seen problems reported that have to do with “Field or Variable Already Exists”. To each their own, but I like my declares all in one place - an old COBOL habit.
No. Global variables remain active until Panorama quits or until you remove it with the undefine statement. If you must use global variables, you should always use the undefine statement when they are no longer needed.
Michael, “…and remain active until you close the database.” That’s in the definition of FileGlobal. The WindowGlobal is another “short-lived” global variable. You are correct that the {just] Global sticks around for the duration of Panorama’s running - it doesn’t have a qualifier like “File” or “Window”.
Styles change. Early programming had GoTo statements that were horribly misused by the undisciplined - GoTo statements were not evil, they were just used in evil ways.
“Globals” used the be the answer for everything. Problem was, as the world got smaller and people started sharing things, you might use a procedure or file from someone who used a global variable for one thing, and, amazing but true, you might combine that procedure/file with your own set of files where you used the same-named global for something else. Even if your “undefine” it wouldn’t stop an issue where both globals were messing each other up while they were “alive” at the same time. In fact, it might make the problem harder to find. So considerations of Scope become much more important.
When you are working with only your own stuff, you know (usually) what you created. And as Jim mentioned, the Search features are much better now. But when you are working/fixing someone else’s routines, and some variable pops up, it’s handy to know where it came from.
But you certainly wouldn’t want to accidentally use the same variable name for different things. Panorama won’t complain, there will be no error message, but it will probably not give you the results you were expecting. That’s why I like to use fairly long, descriptive variable names. Makes it easier to read the code later when you’ve forgotten everything about it, and reduces the chance of accidentally using a single variable for two different purposes.
