To avoid complex explanations in the large previous lesson covering Documents, we have decided to discuss all the theoretical issues here in an individual lesson. Here we will pay attention to the issues we have omitted or only briefly covered earlier.
This theory is very important for understanding why we use the specific approaches described in the previous lessons. This information is vital for those readers who are willing to develop configurations themselves in the future.
But if you find this section too complicated, you can skip it and return here later. This will in no way damage the development of the training configuration that we discuss in this book.
In the previous lesson, you created a form of the Goods receipt document and made this form the default one. What does it mean?
Each applied object in a configuration has a certain number of default forms. These forms offer various ways of displaying the object data.
If a developer does not specify custom default forms, the platform generates required object forms automatically when they are called.
This feature reduces the development time because you can use the default forms instead of creating them manually.
The platform generates the forms dynamically, on the fly. Forms are created at the moment they are called (both interactively and from 1C:Enterprise script).
For example, the list form of the Customers catalog is created both when, on the main menu, you point to All functions, point to Catalogs, and click Customers, and when the GetForm() global method is called (listing 5.1).
Listing 5.1. Calling the GetForm() method
ListForm = GetForm("Catalog.Customers.ListForm");
Another fact worth mentioning is that the assortment of default forms available for a configuration object might not match the list of forms that you can create for that object using the form wizard.
For example, for most registers you can create a default list form in Designer. However, if you open the form wizard for a register, you will see that, in addition to a list form, you have the option to create a register record set form, which is not available in the list of default forms.
This is because the assortment of default forms is determined based on how the data may need to be displayed to users during their work. Developers have the option to create custom forms and make them the default forms, or they can use the automatically generated forms.
In contrast, the form wizard is based on the developer needs. If a developer needs to use a record set form for some register rather than the usual list form, they can do it by creating the form in the wizard and then specifying it as the default register form. But this will not make any real difference in the system operation logic.