1C:Enterprise forms are intended for viewing and editing data stored in the database. Forms can belong to specific configuration objects, or they can belong to the entire applied solution.
For example, the Items catalog can have multiple forms for specific purposes: editing catalog items, displaying the list of items, and so on.
At the same time, forms that do not belong to specific configuration objects (common forms) are available.
You can perform standard actions on each configuration object. For example, you might want to display the list of catalog items, display individual catalog items, display a catalog group, or select items and item groups from the catalog. For documents, this list is shorter and can include viewing the list of documents, selecting documents from the list, and viewing individual documents.
A set of main object forms is intended for performing standard actions on applied solution object data. Any form subordinate to the object can be selected as the main form. For example, the Items catalog can have the following main forms.
The PurchaseInvoice document will have a different set of main forms.
Therefore, if a user attempts to view the list of the Items catalog or the list of PurchaseInvoice documents, the platform will open forms that are specified as the main list forms for these objects.
Autogenerated forms are an important feature of 1C:Enterprise. They eliminate the need to develop all available forms for each configuration object. Developers only have to add new configuration objects, while the platform automatically generates the forms required for displaying object data at run time.
Developers only need to create custom forms for applied solution objects if they want the form design or behavior to be different from the autogenerated forms.
Linking forms to data
The fact that a form belongs to a specific configuration object does not define which data is shown on the form. For example, the fact that a form belongs to the Items catalog allows specifying it as one of the main forms for this catalog, but it does not define which data is displayed on the form or its behavior.
Form attributes are used to link forms to data. They store the set of data displayed on the form. All of the forms have identical behavior, regardless of what kind of data they display. You can set one of the form attributes as its main attribute (it is displayed in bold in the attribute list) to complement the standard form behavior with features related to the type of its main attribute.
For example, if the main form attribute is the PurchaseInvoice document, the platform will prompt the user to confirm the writing and posting of this document on closing the form. If the main form attribute is the Items catalog, the platform will not prompt for confirmation on closing the form.
Developers do not have to draw forms manually, "pixel by pixel". A form only stores the logical description of its content. The platform automatically arranges the form items when it draws the form.
The part of the form that is visible to users is described as a tree of form items.
Form items can include text boxes, buttons, checkboxes, radio buttons, and so on. A form item can also represent a group that contains other items. A group can be displayed as a pane with a border, a pane with pages (tabs), a page, or a command bar. Besides that, an item can be a table, which contains other items (columns). The item structure describes the look of the form.
The form functionality is described by its attributes and commands. Attributes represent data available in the form, while commands represent available actions. A form developer has to add all required attributes and commands to the form, create form items for displaying them, and combine the items into groups if necessary.
The platform generates the form layout, which will be displayed to users, based on this logical description. It takes into account various properties of the displayed data, such as its type, in order to generate a user-friendly layout.
A variety of form layout settings are available to developers. They define the order of items and their desired width and height. However, this is just additional information that helps the platform generate the form layout.
In addition, to form commands, developers can use global commands in their forms. Global commands belong to the command interface of the entire configuration. In addition to that, developers have the option to use parametrized commands that open new forms based on the current form data. For example, a parameterized command can open an inventory balances report for a warehouse that is currently selected in a goods issue document.
Form implementation specifics
Managed forms have the following specifics:
- A form exists both on the client and on the server
It performs the client/server interaction (sends data and item display settings).
- A form does not process applied objects
A form processes universal FormData objects. Applied objects are only processed on the server during the execution of specific operations.
When a form is opened:
The object is read from the database
The object is converted to form data
The object is deleted from memory
Form data is sent to the client
Form data is received from the client
Form data is converted to the object
The object is recorded to the database
The object is deleted from memory