Okay, here is another formulated 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. [MUSIC] Each metadata class knows what purpose it will be used for and has the set of standard forms to make this behavior possible. For example, every catalog has the List form, to list all the items. The single item form, to show the detailed info and the 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 catalog's 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 held, but I do need the Product Type on the brand. And here is my form. This window is called the form editor. This is where we change the form appearance and the behavior. This frame to the left shows all visual elements off 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 forms 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. The next 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 the relative positions just like this. Another type of group is a Pages group. We use it to split the forms 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. It 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 several commands together to get something like this. Now, how about all these 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 will 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 forms attributes leave on this tap. And here is our list. It has a dynamic list type and takes its data from this table down here. So let me explain what's really going on. These are the forms, visual elements. And these are the forms attributes. Forms visual elements and forms 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 users input. Attributes talk to a database. They received 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 data path property, which in our case points from the list element to the least attributes. The least attribute is the dynamic list, which means it knows how to read data by portions, keeping in memory only the part that feeds to the screen. And this property tells the dynamic list 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 mean is that, they know how to do things. They have complex behavior, usually connected with the info base data. Our old friend DynamicList knows how to read data page by page. The CatalogObject knows how to use 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 this without the Form it leaves on. So when the Form gets open, the Main Attribute places outcomes to the form so that the user can work with them. If I uncheck this main check box, the entire common box disappears. If I had another attribute of the catalog type, for example. And declare it main, there will be a completely different set of Commands meant to control the single catalog item rather than the list of items. As for the other attributes that cannot be declared Main, you can add them to 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. Sorry. [MUSIC]
