![]() | ![]() | |
| Make/Model | Device Version | Connection Type |
| CQS/Variables | N/A | N/A |
This driver does not control a device. It exists just to allow you to create system wide data storage fields. These can be used in your macros to store information that can be referenced in later macro invocations. For instance, if you wanted to support a 'mood' in your system, you could create a mood field, with for instance enumerated values Party, Read, Sleep, Eat and so forth, and you could write to this field at any time to set a mood. Then any of your macros that you invoke could look at this field and do things in particular ways for that mood.
This is just one example and you can probably find many ways to use it. Here is a picture of the client side interface, which is used to configure the driver. The configuration just consists of the fields that you want the driver to create when it runs.
You set the data type of the field, it's limits, and optionally a default value for it that the driver should set for each field when it first runs, else you will get a default initial value. You can use the Set Value field to modify the value of the selected field. This is mostly for testing purposes, since normally they would get changed in the course of running macros. However, one reason for setting the value is so that you can make it the default value. When you press the Make Default button, the current value of the field is set as the default, which will cause that value to be initially set any time the driver reloads.
Use the Edit Fields button to bring up the edit dialog that allows you to add or remove fields or modify the attributes of existing fields (see the Quirks section below before modifying fields.) You will see the following dialog box:
Use the Add button to add new fields, Delete to remove the selected field, Save to save any changes and exit, and cancel to exit without saving any changes. When you save, the new field list will be uploaded to the server side driver, which will take this list and update it's registered field list, and set each field to it's default value.
Though you can easily change the definitions of the fields you configure, be careful of doing this after you have started using those fields in macros, user interfaces, etc... because it can cause unforeseen problems. In particular with user interfaces, many widgets only allow you to associate them fields that have certain attributes, and if you change those attributes afterwards, you can cause those widgets to fail to work correctly. So treat these fields as fairly static entities unless you are going to be sure to update any uses of them.
Since this driver doesn't control a device really, it doesn't have any connection configuration issues.
This driver allows you to define the fields, so there is no pre-defined list of fields to document.