FoxPro public and local variables

Even if you never wrote a program in your previous live, you will certainly start it when you use Tool&Task routines! It is a outstanding ability of FoxPro® to compile source during runtime. This means a FoxPro executable (in this case tt.exe) can compile and run source written in Foxpro! Hence, you can write some lines of source and Tool&Task has inherited the FoxPro skill to compile this source and run it.

Why should I write software? I thought Tool&Task does a lot of jobs for me?

At the moment, we are working on version 2.86 and this includes a new routine 'crawl my shop'. The idea behing is, this program should enable you to supply a sitemap for Google® which enables their crawler (=googlebot) to index all products of your shop in seconds. Sure, Tool&Task needs to receive the procedure of your shop software and the parameters to call this procedure for each product. Last but not least, it needs a list of your products. But both is available when you have access to your own data. Since there is a huge variety how to access these data in different pieces of shop software, it needs a couple of lines to tell the TT-crawler how to read them. As soon as TT understands this information, the following way to the target (=sitemap.xml) is the same for all shops and Tool&Task can finish the job.

It is easier than you might think, and if you have problems to write these lines, there might be a friend or colleque who can do it or you contact us. Nevertheless, before you start, some understanding about a programming language is essential. Try to understand the difference between a public and a local variable from this chapter

 

Search the internet about public and local variables in FoxPro® and you find a lot of information and discussion. Here, we try to give you a simple explanation which should be easy to understand and to follow.

Public Variables

Each program has a routine to begin with. In all our projects this routine is top.prg. Top.prg has definitions for the whole software and creates a menue and a toolbar to enable the user to select different actions of Tool&Task.

When you define a variable in top.prg, FoxPro has this variable available in all subroutines called by top.prg. This variable might be used by the program you write and start within tt.exe. If you introduce a new variable in a subroutine, you might use this variable in all subroutine called by the creating routine but not backwards. In other words, this variable is forgotten as soon as the subroutine closes and the execution returns to the program which called this subroutine.

Exeption: If you define this subroutine PUBLIC (or public, FoxPro is not case sensitive), it will survive the step back to the calling routine and remain defined in all routines of your software.

Recommandation: If you want a variable to be available everywhere, declare it public! Even if defined in top and available in following routines anyhow, declare it public.

It is easier to read and understand programs, if you immediately see: this is a public variable! This is certainly the case when you start all public variables with the same letter. We use the letter 'g' in Tool&Task (this is a C-programmer habbit since these public variables are called global in the programming language C)

Please accept, that we not only took the initial 'g' from C but also the word global (instead of PUBLIC).

You can use all TT public variables in your software. The global variable gUserDataTT is a good example!

And what if I change the path in gUserDataTT? Tool&Task will crash after completing you program since it will not find any table in the following tasks. But it is pretty easy: Don't do it!

 

Local Variables

To be sure, a variable is only available in your program and not even survives the call of a subroutine, declare it LOCAL. A good habbit is, to start names of local variables with a lower case 'l'.

If you use the following source, you will get the errors as expained. Please read the source and try to fully understand how FoxPro handles variables. It explains a typical FoxPro pitfall which a C programmer would never experience in the language of his choice!

To understand this pitfall, keep in mind: whenever you define a variable in a calling program and change it in a called procedure, it is changed in the calling program as well since it is the same piece of memory! Hence, if you do not want that, define local variables.