OK, here is another forms-related question for you. How does the Platform know what form to open when I do this? Or when I do that? Well, this is how. Each Metadata Class knows what purpose it will be used for and has the set of standard forms to make this behaviour possible. For example, every Catalog has the list form (to list all the items), the single item form (to show the detailed info) andthe choice form (to select an item and use its reference elsewhere).
We don’t have any explicit forms here, so whenever the Platform needs to open a form, it uses the standard one from the Catalogs Metadata Class. I can create any number of forms belonging to this metadata object and say to the Platform which one to use where.
We already know, how to create an explicit form, so let’s create the List form here. I don’t need the Code field, but I do need the ProductType and the Brand. And here is my form.
This window is called the form editor. This is where we change the forms appearance and behaviour. This frame to the left shows all visual elements of the form. You can play clicking on each of them and see how they get highlighted in the preview frame down here.
There are many different types of the form visual elements, so let’s check out how they look and what they do.
The simplest one is called a Decoration. It can be a label - some text you want to put on the form, or a picture. And here they are in the preview.
Thenext one is called a regular group. It can be with or without a visual representation and you want to use it to combine a few elements together and then adjust their relative positions. Just like this.
Another type of a group is a Pages group. We use it to split the form’s elements between several pages to make the form look cleaner and to be more usable.
Next up is a Button, that’s meant, obviously, to be pressed by a user and run some command. You can select one of the standard commands, one of the interface commands from the last video, or you can create your own command and write a piece of code you want to be executed when the button is pressed.
Command bars are the special type of group that allows you to combine a several commands together to get something like this.
Now, how about all this data that was somehow taken from the database and shown here in the form? How did they get here in the first place?
Let me show you what happened. This table here is apparently this form element, right? If we open its properties, we’ll see that it has the Table type. This is the same Table type we have already seen in this list here.
This List element takes its data from this List attribute. All the form’s attributes live on this tab and here is our List. It has a DynamicList type and takes its data from this table down here.
So, let me explain what’s really going on. These are the form’s visual elements. And these are the form’s attributes. Form’s visual elements and form’s attributes live in the same form, but they do very different jobs. Visual elements talk to a user. They display themselves on the screen and receive user’s input. Attributes talk to a database. They retrieve data from the database and send them back. And, of course, Elements and Attributes talk to each other. Elements are connected to the Attributes through the DataPath property which in our case points from the List element to the List attribute. The List attribute is the DynamicList which means it knows how to read data by portions, keeping in the memory only the part that fits to the screen. And this property tells the DynamicList what data to read.
The interesting thing about this List attribute is that it’s marked as Main. There are many different types of the form attributes but only some of them can be honored with this title. And this is the complete list of these cool dudes. The difference between them and those who can never become Main, is that they know how to do things. They have complex behaviour usually connected with the infobase data. Our old friend DynamicList knows how to read data page by page, the CatalogObject knows how to read a single Catalog item and write it back, the DocumentObject does the same for the Documents and so on.
Of course, the Main attribute couldn’t do any of these without the form it lives on. So, when the form gets open the Main attribute places all its commands to the form, so that a user can work with them. If I uncheck this Main checkbox, the entire command box disappears. If I add another attribute of the CatalogObject type, for example, and declare it Main there will be a completely different set of commands, meant to control the single Catalog item rather then the list of items.
As for the other attributes that cannot be declared Main, you can add them too if you want. But remember - they don’t do much by themselves. And the responsibility of making them work is all yours. Meaning, you will need to write some code.