GroundControl will accept variables in place of regular function arguments. In English, this means that anywhere you would provide a function with parameters, you can put a variable instead, provided the variable contains what you were originally going to provide.

For example, suppose you want to display a message box. The easy way of doing this is:


MessageBox(“Hello, this is a sample message”)

The alternate way, using variables might look like this:


PutVar(%M,“Hello, this is a sample message”)
MessageBox(%M)


First, we load the text string into variable %M. Then, we call the MessageBox function, but instead of explicitly giving it the string we want to display, we pass the name of the variable where the string is stored. When GroundControl executes the MessageBox statement, it looks at the parameter to decide if it’s a variable or not. If it is, it replaces the %M you typed with the contents of %M instead. All variables begin with %, so GroundControl can identify them.

Let’s try another example. We will write a Repeat function using a variable %R. Here’s the original statement:


Repeat(Beep(),10)

Here’s the variable version:

    PutVar(%R,10)
    Repeat(Beep(),%R)
.
Again, instead of explicitly specifying ten for the repeat count, we put the value ten in variable %R, and specify %R for the repeat count. GroundControl recognizes a varaible in the Repeat statement, and substitutes the contents, which is the value ten.

You can do this to any function. Look at these examples:

1.    PutVar(%A,"Calculator")

ActivateWindow(%A)    has same effect as ActivateWindow(“Calculator”)

2.    PutVar(%A,"C:\MYFILES")

CreateDirectory(%A)    has same effect as CreateDirectory(“C:\MYFILES”)

3.    3.    PutVar(%A,”a new line of text”)
WriteToFile("mylog.txt",%A)    has same effect as WriteToFile(“mylog.txt”,”a new line of text”)


Which variables you use for which purpose is up to you. It helps to associate the variable letter with what it’s storing, so you might want to store a name in %N, a counter in %C, disk space size in %D or %S, or so on.

Why do we want to use variables? It looks as though it takes twice as many statements to do what we wanted. If we know what has to go in them before they can be used, why make two steps out of it? There are many reasons. You might want to reuse certain strings or values in multiple statements. Instead of typing in the same string, use a variable. That way, if the string ever changes, you only have to fix it in one place. A person’s name, a directory path on a drive, a maximum file size, a program name – these are all examples of something you might want to put in a variable for storage.

There are more important uses for variables. They act as temporary storage locations for data coming in and out of your macro. You just learned that any function will accept a variable for a parameter, and that it’s the contents of the variable that are substituted by GroundControl. You also learned that you use PutVar to load a variable with a value of some type. There are several other ways of getting data into variables that we haven’t looked at yet:

1. Interactive Input with InputBox

InputBox now takes an optional parameter for the variable name. The response entered by the user is stored in the variable. This means you can send their response to any function. If you ask for a filename, you can send it to DeleteFile, FindFile, WriteToIniFile, FileExist, FileOlderThan, CopyFile, etc. You can ask for a username, and log it using LogEvent, LogError, WriteToFile, etc. You could also send the username to another program using SendKeys or DDE.

For example:

InputBox(“What is your favorite color”,%C)
    IfEquals(%C,”Blue”,MessageBox(“Mine too!”))
    InputBox(“What is your favorite number”,%C)
    IfEquals(%C,21, MessageBox(“Mine too!”))

2. System Information

There is a new function called GetSystem to return the system values identified by the system constants used in LogSystem. The function takes one parameter, the variable in which to store the result:

GetSystem(%A,DISK_C_FREE)

Dump()

GetSystem(%A,MEMORY_TOTALPHYSICAL)

Dump()

GetSystem(%A,COMPUTER_NAME)

Dump()

3. File Size

You can retrieve the size of a file in bytes via the GetFileSize function. The first parameter is the name of a file, the second is the variable in which to store the result. For example, the following will write the size of the autoexec.bat file to a logfile:

GetFileSize( “c:\autoexec.bat”,%B)
    WriteLineToFile(“mylog.txt”,”The file size is: “)
    WriteLineToFile(“mylog.txt”,%B)


This created file will look like this:

The file size is:    1196

Notice in the above example that the text “mylog.txt” was used twice. Here is a place where a storage variable could be used. For example:

GetFileSize( “c:\autoexec.bat”,%B)

PutVar(%F,“mylog.txt”)

WriteLineToFile(%F,”The file size is: “)

WriteLineToFile(%F,%B)

4. Reading the Clipboard

There is a new function to pull the contents of the ClipBoard into a variable. Simply specify the variable to use:

GetClipBoard(%C)

Dump()

This is useful if you want to send a copy command to another application to have it copy some results you want to the ClipBoard, and then pull them into your macro with GetClipBoard(). This only works if the contents of the ClipBoard are in text format.

5. Reading the Registry

You can use GetFromRegistry() to pull values from the registry. You need three parameters, one for the registry path, one for the item you want to retrieve, and one specifying the variable where you want the result placed:

GetFromRegistry("HKEY_LOCAL_MACHINE\SYSTEM\SETUP","cmdline",%B)

Dump()

Registry key/paths tend to become long in a hurry. If you have multiple reads to perform from the same key/path, use a variable to store the key/path, and your macro will be much more readable:

PutVar(“%K”,”HKEY_LOCAL_MACHINE\SYSTEM\SETUP”)

GetFromRegistry(%K,"cmdline",%A)

GetFromRegistry(%K,"systempartition",%B)

GetFromRegistry(%K,"systemprefix",%C)

GetFromRegistry(%K,"setuptype”,%D)

Dump()

Use extreme caution when working within the registry!

6. Reading INI files

You can use ReadFromIniFile() to pull values from INI files. You need three parameters, one to specify the file and one for the section and item. The last parameter is the variable where the result should be placed. This is powerful because you can use your own ini files to store variables or results of any kind. Suppose you ran a macro every morning to monitor disk space. You can use your own ini file to store the disk space each day, so you can see if you are running out. Let’s create a file called monitor.ini, and store the disk space in a section called “diskspace”, and keep one entry for each drive on your system. The ini file looks like this:

[diskspace]
    cdrive=142351362

ddrive=1235112355

edrive=45236418

The macro will check the disk space every morning, then compare it to yesterday’s values stored in the ini file. It will then have to write the new disk spaces back into the ini file for the next day.

// get yesterdays space on disk c, put it in %Y

GetFromIniFile("C:\gc\monitor.ini","[diskspace]cdrive”,%Y)

// get todays space into %T

GetSystem(%T,DISK_C_FREE)

// warn the user

IfLessThan(%T,%Y,LogEvent(“Less space than yesterday on C drive”))

//update the ini file with the new value

WriteToIniFile(“C:\gc\monitor.ini”,”[diskspace]cdrive”,%T)

// repeat this code for other drives …


Of course, you can go crazy with variations of files, sections, and items. Ini files allow a ton of flexibility for permanently storing data.

7.    7.    Incrementing and Decrementing

There may be instances when you want to use variables as counters, to track how often a macro or function has been called. The new Increment and Decrement functions allow you to do this easily.

Sales: (661) 334-4888

Support:

e-mail: sales@acrasoft.com

e-mail: support@acrasoft.com