In this lesson we will introduce some standard object form development techniques.
First, we will explain how data is displayed in forms and what data types are used here.
It is important to understand the principles of displaying data in 1C:Enterprise platform forms.
The fact that a form belongs to a certain configuration object does not determine which data is available for displaying in the form.
For example, you can create a common form that is not subordinate to any configuration object, but displays a catalog list, or a document that can be edited, or something else. However, you cannot use this form as a default form for a specific operation.
A form and its controls are inherently separated from configuration objects. To have a form to display certain data, you have to link the form itself or its controls to some data. If you do not specify the links, the controls are not displayed in the form at all (except for the controls that define form appearance).
When you use a form generation wizard, Designer creates the links automatically. When you create a form manually, you can define these links by specifying form properties or form control properties (fig. 27.1).
Fig. 27.1. Linking form controls to data
The link between a form control and data that it displays is defined in the DataPath property.
A link between a data item and a form or its control is established using form attributes. The list of available form attributes is displayed on the Attributes tab in the form editor.
Among all the form attributes usually there is a main attribute (displayed in bold type). This attribute defines the data source for the form in general. The type of the main form attribute determines not only the data type to be displayed in the form controls, but also the form behavior.
For example, if the main form attribute has DocumentObject.GoodsReceipt type, when the form is closed, the platform displays a confirmation request before saving and posting the document. However, if the main form attribute has CatalogObject.Customers type, the confirmation request is not displayed when the form is closed.
Data sources have similar effect on form controls. For example, if a table uses a DynamicList form attribute as its data source, its set of columns varies depending on the object used as the main table of this dynamic list (for example, AccumulationRegister.BalanceOfMaterials or Catalog.MaterialsAndServices).
The same is true for the Command bar control. If the AutoFill property of a command bar is set to True, changing the data source (or more precisely, the action source) changes the set of commands displayed in the bar.
The fact that a form or its controls can be linked to data items of various types is the reason for the forms and controls to have multiple extensions.
An extension is a set of additional properties, methods, and events belonging to a form or form control. Availability of an extension is determined either by the type of data displayed in the form or control, or by the position of the form control within other controls.
To better understand how it works, let us create a form.
- Start creating a default list form for the MaterialsAndServices catalog but do not click the Finish button in the form wizard as you have done earlier.
- Click Next.
- Add the MaterialServiceType field to the List table (in addition to the Description and Code fields), then click Finish (fig. 27.2).
Fig. 27.2. MaterialsAndServices catalog list form
So we will explain the extensions on the example of the MaterialServiceType field located in the List table of the MaterialsAndServices catalog form.
The form itself displays the data of a DynamicList object (the main form attribute has DynamicList type, fig. 27.3).
Fig. 27.3. Main list form attribute
This is why the properties, methods, and events of Managed form extension for dynamic lists are added to the properties, methods, and events of the ManagedForm 1C:Enterprise script object (fig. 27.4).
Fig. 27.4. Extension for dynamic lists context added to form context
This adds new properties to the form: CurrentRow, Filter, and more.
Now take a look at the List table.
Since the table displays a dynamic list, the properties, methods, and events of Managed form extension for dynamic lists are added to the properties, methods, and events of the FormTable 1C:Enterprise script object (fig. 27.5).
Fig. 27.5. Dynamic list extension context added to table context
This adds new properties to the List table: AutoRefresh, ShowRoot, and more.
Finally, look at the MaterialServiceType field.
This field is a text box linked to an attribute of the EnumRef.MaterialServiceTypes type.
This adds the properties, methods, and events of Form field extension for a text box to the properties, methods, and events of the FormField 1C:Enterprise script object (fig. 27.6).
Fig. 27.6. Text box extension context added to form field context
This adds new properties to the MaterialServiceType field: QuickChoice, SelectedText, and more.