(why do you need the driver it there is already variables built in), etc. And how tokens work in relation to variables.
The variables driver really isn't related to variables at all. It just was given the name variables driver becasue it allows you to create arbitrary fields that are used basically like variables are, i.e. as scratch pad storage for values. However, being a device driver, those scratch pad values are available throughout the whole network. So you'd use that if you need some information that every CQC program can see and react to. Normally they see and react to the fields of regular device drivers, i.e. to the state of devices under CQC's control. But the variables driver is just a 'pseudo device' whose fields only take the values that your own automation logic sets in them.
Local variables exist only for the length of the action event that they are defined within. So they are for very temporary scratch pad value usage within the actions that create them. They can't clash with any other variable names since only the action that created them can see them, and they don't need to be cleaned up since they automatically go away when the action ends. So, if you want to, say, get the value of a thermo, add one, and write it back out, you'd use a local variable to do that. It doesn't need to exist outside of the action. It's just a scratch value to use and then discard.
Global variables are used to pass information from one action to another, so they don't go away when the action ends. But they are not visible outside of the program that is running the action. Actually, they are more restricted that the program, they are restricted to some 'global variable space'. In the interface viewer that is effectively equivalent to the program. So global variables (unless you explicitly clean them up) last as long as the IV is running.
But in reality they are limited to the IV window displaying the interface that invoked the action. So, within the Admin Interface, where you can load multiple IV windows, each one has its own global variable space. Otherwise, they could step all over each others toes because they could accidentally affect each other's global variables. The event server has its own global variable space, so that event handlers can store info and reuse it the next time to remember things across event invocations.
Anyway, the important thing to remember, in terms of interfaces, is that global variables exist to let you pass information from one action to the next. Some of the ways this can be used are:
- It lets you create reusable popup templates, where some of the info displayed or something that controls how it acts, can be set in an action, then the popup invoked, which then runs another action (as the popup loads) which can use that info to set itself up.
- When the user clicks on a piece of cover art in the cover art browser, it lets you store info about about the title selected, then invoke a preview template. That template uses that information to set up the media preview widgets to show info from that selected title.
- Widgets can now be associated with variables. So, for instance, if you wanted to have an image widget in the upper right corner that showed an image indicating which mode the interface was in (i.e. what the user has selected to load into some main overlay area, media, lighting, cameras, etc...), that used to not be very easy to do. You could do it if you only ever changed what was loaded in that overlay directly via the buttons in the main template, because you could just send a command to the image to change what it is displaying, then load a new template into the overlay.
But if you changed what was loaded from within the overlay itself, there was no way to target that image up in the main template. Now, you can create a global variable of an 'enumerated' type, i.e. it has a small set of textual values, then create an enumerated image widget and associate it with that variable. Then, you can change the value of the variable anywhere and the enumerated image widget will update.
Before, you'd have had to do that using the variables driver, because widgets could only be associated with fields. But, that meant you'd have to have a separate field for each possible client, and each client would have to be sure to look at the correct field. So it was far harder to do than it is now.
- You can also have a single set of widgets that do things based on the value of one or more global variables. I.e. not multiple templates that you can load one at a time into an overlay, but just some widgets that are always there. They use the value of one or more variables to decide what devices/fields to do something to. You can then have a set of 'radio button' type check box widgets, which are associated with a global variable. So you press one of the, that one lights up because it sets the variable to the value that that check box is set up to consider its 'true' value, and any other previously selected one turns off. Then you can press one of the other widgets, and it will now operate on whatever you selected with the check box, because it looks at the value of the global variable to know what to do.
- Within the event server, if you had some scheduled event that you wanted to toggle between two or three things, you could create a global variable that you initial set to 1 (you see it doesn't exist so you create it and set it to 1), then each time the event is run, it increments the value, wrapping back to 1 when it goes beyond the maximum value. So it would allow that event to remember what it did last time and move forward appropriately. You could use the variables driver for this as well, but there's no need to and the global variable will work fine for something like this.
Those are just some obvious examples of how you can use them. They effectively make the interface system a point and click programmable GUI, where you can create very powerful and interactive and reusable interfaces.
haha