One of the less intuitive aspects of working with DesignBais is that things aren’t always done directly. We don’t always use Field=Data to assign data to a field. We frequently need to tell the field where it needs to go to get its data, and then we load that data source as necessary.
As one example, you might have two dropdown lists, one to allow the user to select Salesman1 and one for Salesman2. Rather than populating each list separately, we tell each field where their source data can be found: We can specify a Lookup File in the field definition or in the field properties in the Forms Designer. Or we can specify a Lookup Work Field using the V:FieldName syntax, and then populate that work field from code, with data structured as follows:
DBWORK<Atb, index, 1> = ID
DBWORK<Atb, index, 2> = Description
The atb is whatever attribute you assign to the FieldName. The index number is the position in the dropdown list. The user sees the description, and when they select that item in the dropdown list the ID is sent as the DBVALUE in the Validate event for the dropdown list.
The point here is that the dropdown list isn’t populated directly – it gets data indirectly from a work field, and that is what we are populating. If you change the data in the work field, any fields that get their data from that attribute will change immediately.
As another example, we don’t often say "disable that field" from code. To disable a field you need to put a work field on a form, set it to a value, assign your display field to a specific section, then in Section control you say "if the work field is some value, disable this section". It’s not the field per-se that you’re disabling, it’s the section. And you aren’t telling the section to be disabled, you’re telling it to get its instructions from whatever work variable you specify. Again, one work field can be used to trigger many section settings.
Digression #1: For those of you who are familiar with other development environments, this sort of indirection isn’t unusual, in fact it’s the norm for many development environments like ASP.NET, or languages like Java. In ASP.NET we will have a grid on a form, and the form can (doesn’t need to) get its data from an ObjectDataSource. That source can be a connection to a data file, an XML file, or another structured variable – which is exactly what DesignBais uses. With Java and other Object Oriented languages, we don’t always create an object directly from a class, we may ask a "factory" to provide an object to us of a given type. (This is known as the Singleton Pattern if anyone is curious.)