Get the value of variable 1c 8.3. Managed form credentials (1Cv8). Design patterns or the wisdom of generations

Form details

The set of form attributes describes the composition of the data that is displayed, edited or stored in the form. At the same time, the form details by themselves do not provide the ability to display and edit data. Form elements (see the section "Form Elements" of this chapter), associated with form attributes, are used for displaying and editing. The set of all the form details will be called form data.

Important! It must be remembered that, unlike regular forms, all data managed form must be described in the form of requisites. It is not allowed to use form module variables as data sources for form elements.

It is possible to assign The main requisite of the form, that is, a props that will define the standard functionality of the form (form extension). It should be remembered that a form can have only one main attribute.

Expanding the form- these are additional properties, methods and parameters of the ManagedForm object form that are specific to the object that is the main element of the form.

In the process of developing a form, you can explicitly set the ability to view and edit specific details of the form, in terms of roles, using the View and Edit properties (for more details, see the section "Role-based form customization" of the "Editors" chapter). In addition, the availability of a particular attribute in the form itself can be configured using functional options (for more details on functional options, see the chapter "Managing the configuration interface").

Form props property Stored data is a sign that an interactive change of the props will lead to an attempt to block the form data for editing, as well as to automatic installation a sign of form modification.

Data types available in managed form

A managed form also differs from a regular form in the types of data it works with. If the usual form works with most of the types that 1C: Enterprise provides (including the type DirectoryObject, DocumentObject, etc.), then the following categories of types can be distinguished in the managed form:

• types that are directly used in the form are those that exist on the side of the thin and Web client (for example, Number, ReferenceRef.Products, GraphicalSchema, TabularDocument);

• types that will be converted to special data types - managed form data types. Such types are displayed in the list of form attributes in parentheses, for example (ReferenceObject.Goods);

• dynamic list (see the section "Dynamic list" of this chapter for more details).

Converting Application Objects to Form Data

Some application types (such as DirectoryObject, etc.) do not exist on the side of thin and Web clients (for more details, see the chapter "The concept of a managed application"). Therefore, to represent such application types in the form, the platform has introduced special data types designed to work in managed forms. This feature of a managed application necessitates the conversion of application objects to form data (and vice versa).

The following data types are used:

• FormDataStructure - contains a set of properties arbitrary type... Properties can be other structures, collections, or structures with collections. This type is represented, for example, in the form DirectoryObject.

• A FormData collection is an array-like list of typed values. An item in a collection is accessed by index or identifier. Access by ID may not be available in some cases. This is due to the type of application object represented by this collection. The identifier can be any integer. This type is represented, for example, in the form tabular part.

• FormDataStructureCollection is an object that is represented as a structure and a collection at the same time. It can be treated like any of these entities. This type is represented, for example, in the form of a set of records.

• FormDataTree - the object is designed to store hierarchical data.

An application object is represented by either one or more form data items. In general, the hierarchy and composition of form data depends on the complexity and interrelationship of the application objects of the managed form.

For example, a document containing a tabular section will be represented by an object of the FormDataStructure type (the document itself), to which an object of the FormDataCollection type (tabular section of the document) is subordinate.

Important! When designing a configuration, it is important to remember that application objects are only available on the server, while form data objects can be used on both the server and the client.

Passing Data Between the Client-Side and Back-end of a Managed Form

In fact, we can say that form data is a unified representation of the data of various application objects, with which the form works in a uniform way and which are present both on the server and on the client. That is, the form contains some "projection" of the data of the application objects in the form of its own data types and converts between them, if necessary. However, if a configuration developer implements his own data processing algorithm, then he must perform data conversion (from specialized types to applied types and vice versa) independently.

When editing the form attributes in a specialized editor (for more details, see the "Form attributes" section of the "Editors" chapter), it is possible to influence the transfer of data between the client and the server while the form is running. To do this, use the column of the attribute editor. Always use... The effect of this property differs for three types of attributes:

• For an attribute subordinate to a dynamic list (dynamic list column):
  • property on - the attribute is always read from the database and included in the form data;
  • property off - the props are read from the database and are included in the form data only when there is one visible in this moment form element associated with a props or its subordinate props.

• For props subordinate to the movement collection:
  • property on - document movements are read from the database and will be present in the form data;
  • the property is disabled - document movements will not be read from the database and will not be included in the form data (if there is no form element referring to document movements).

• Other details of the form:
  • property enabled - the attribute will be present in the form data, regardless of whether or not there is at least one form element that is associated with the attribute or its subordinate attribute;
  • property off - the props will be present in the form data only if there is a form element associated with the props or its subordinate props. Unlike the attributes of a dynamic list, the visibility of the element associated with the attribute does not matter here.

Note. It should be remembered that the property set on the parent attribute affects all subordinate attributes. For example, if the Use property is always cleared for the tabular section of the document, then the system considers that this property is also cleared for all subordinate attributes (despite the actual state of the property).

Methods for Converting Application Object Data to Form Data

There is a set of global methods for converting application objects to form data and vice versa:

• ValueInForm Data (),
• FormDataValue (),
• CopyFormData ().

Important! Methods that work with application objects are available only in server procedures. The method for copying values ​​between form data is available on the server and on the client, since it does not require application objects as parameters.

When converting form data into an application object, consider compatibility.

• ValueInForm Data () - converts an object applied type to form data;
• FormDataValue () - converts form data into an object of an applied type;
• CopyFormData () - copies form data with a compatible structure. Returns True if the copy was made, or False if the structure of the objects is incompatible.

Note. When performing standard actions (opening a form, executing the standard Write command, etc.) of a form with the main attributes, the transformation is performed automatically.

Here's an example of how to use data transformation in your own algorithms.

& AtServer Procedure OnCreateAtServer (Failure, StandardProcessing)

ObjectObject = Reference books.Goods.FindByDescription ("Coffee pot"). GetObject (); ValueVDataForm (ObjectObject, Object);

End of Procedure

& OnClient Procedure Write ()

WriteAtServer ();

End of Procedure

& AtServer Procedure WriteAtServer ()

ObjectObject = FormDataValue (Object, Type ("DirectoryObject.Goods")); ObjectObject.Write ();

End of Procedure

Also, the ManagedForm object has methods available on the server:

• ValueBFormAttribute () - converts an object of the applied type into the specified form attribute.
• Form AttributeValue () - converts the form data attribute into an object of the applied type.

Using these methods is usually more convenient, since they have, for example, information about the type of the form attribute. In addition, the FormPropsBValue () method performs the mapping between the form data and the object, which is used when generating messages. You can read more about this in the chapter "Navigation Service Options".

Let's give an example of using these methods.

& AtServer Procedure RecalculateAtServer ()

// Converts the props Object to an application object. Document = AttributeFormVValue ("Object"); // Performs recalculation using the method defined in the document module. Document.Recalculate (); // Converts the application object back to props. ValueVRequisitForm (Document, "Object");

End of Procedure

Programming interface

FormDataTree (FormDataTree)

• FindById
• GetItems

Description:

Designed for modeling a tree in managed form data.

This object can be serialized to / from XDTO. XDTO type corresponding this object defined in the namespace. XDTO type name:

GetItems

Syntax:

GetElements ()

Returned value:

Type: FormDataTreeElement Collection.

Description:

Gets the collection of items in the top-level tree.

Availability: client, server, thin client, web client.

FindById

Syntax:

FindById (<Идентификатор>)

Options:

<Идентификатор>(mandatory)

Type: Number. The identifier of the tree element.

Returned value:

Type: FormDataTreeElement.

Description:

Gets a collection item by ID.

Availability: client, server, thin client, web client.

FormDataTreeItem (FormDataTreeItem)

Properties:

<Имя свойства> (<Имя свойства>)

• GetId
• GetParent
• GetItems
• Property

Description:

Form data tree element.

FormDataTreeItemCollection (FormDataTreeItemCollection)

Collection Items: FormDataTreeElement

For an object, the collection can be traversed using the operator For each ... From ... Loop. The traversal selects the elements of the collection. It is possible to refer to a collection element using the [...] operator. The index of the element is passed as an argument.

• Insert
• Add
• Index (IndexOf)
• Count
• Clear
• Get (Get)
• Move
• Delete

Description:

Collection of tree elements.

Availability: client, server, thin client, web client.

See also:

• FormDataTreeElement, GetElements method
• FormDataTree, GetElements method

Features of working with a tree of values

Updating the tree

There is a problem fall platforms when updating the tree.

If a node has been expanded in the tree and a subordinate node has been selected, then when the tree is updated with the function ValueInDataForm the platform falls.

Solution: Before upgrading, you need to clear the tree.

For example:

& AtServer Procedure ClearTree (elements) For each element of the elements Loop ClearTree (element.GetElements ()); End of Cycle; elements.Clear (); End of Procedure

& OnServer Procedure FillConceptionTree () dzConceptions = cpProperties.Construct ConceptTree (OnDate, Meta.CurrentIB ()); ClearTree (ConceptTree.GetElements ()); ValueVDataForms (Concept, Concept Tree); End of Procedure

& OnClient Procedure OnDateOnChange (Element) Fill ConceptTree (); End of Procedure

The user's work with reference books and documents in 1C consists of filling in the fields on the form.

1C details are the fields of the reference book and the document that are displayed on the form for the user to fill out.

Let's consider in detail the topic of details in 1C.

What is 1C requisites

Each reference book and 1C document consists of a set of fields. Such fields are called 1C details (for a 1C programmer).

In the configurator, in the 1C configuration tree, open any reference or document and you will see the Requisites branch. This is a list of the requisites (fields) of the directory.

Take a look at how the same 1C details look on the 1C reference form.

Each 1C attribute has properties that indicate what kind of value is stored in the attribute (string, number, etc.) and how the user will work with it.

Click on right click to any 1C property and click Properties. A list of properties of the selected attribute will open in the window on the right.

Basic properties of 1C requisites:

Standard details 1C

As you noticed, the form of the directory contains 1C details that are not listed in the configurator: group, name, BIC.

In the form of the directory list, there are also 1C details that are not in the list: deletion mark.

These are standard 1C details. What it is? Each has a set of 1C details by default. For reference books, this is, for example, a code and a name. For documents, this is the date and number.

Standard 1C details can be viewed as follows:

• Go to the 1C object editor (reference book or document) by double-clicking on it with the mouse
• In the editor that opens, select the Data tab
• Here you can configure the standard details Code and Name of the reference book
• Click the Standard 1C details button to view the full list.

General details 1C

Starting with version 1C 8.2.14, a new Object 1C has appeared in 1C - General details of 1C. Using it, you can add an attribute (field), which will be present in many directories and documents at once.

Properties of the general 1C props:

• Auto-use - adds a common 1C attribute to all directories and documents at once
• Composition - allows you to add a general 1C attribute only to the necessary directories and documents (then auto-use in the Do not use value).

How to add 1C props

Right-click on the 1C Requisites branch of the required directory and select Add.

We need to enter the name of the 1C variable, for example, "Office Address" and the synonym "Office Address". Leave the default type as String, but check the Unlimited length box.

Let's add one more attribute 1C in the same way, just select the Boolean type, let's call it "WorksOnExit".

How to display the props on the 1C form ( fat client 1C)

Let's open the Forms branch of the same directory. To open the form, select the element form and double-click on it with the mouse.

Drag the mouse over the edge of the shape and stretch it (optional item).

In the configurator panel, click the "Data placement" button. You can also use the menu Form / Placement of data.

As you can see, our details are not displayed on the form. Place a check mark on them. And also checkboxes Insert labels and Place automatically.

How to display the details on the 1C form (1C thin client)

Let's open the Forms branch of the same directory. Select the shape of the element and double-click on it with the mouse.

On the Attributes tab, expand the Object line. You will see a list of details added earlier to the directory.

Now just drag the required attribute from the right window to the left one and it will appear on the form.

Form 1C details

In the thick client, the form has its own props. They are located on the Details tab.

These details are not stored in the database, but they can be used on the form for fields that are needed to work with the form.

For example, you added a check mark to the form. When you click it, something happens on the form. The value of the checkbox is not important for you (you do not need to write it down) - it is used only to switch the form when working with it. In this case, you use not a reference book attribute as data, but a form attribute.

Periodic details 1C

In 1C version 7.7, there were periodic requisites. Their meaning is as follows: the meaning of the props is different on different dates. For example, the value for September 1 is one, but for October 1 it is different. Have the same props.

There are no periodic requisites in 1C 8. This is implemented as follows:

The form attributes provide its connection to the data. In this case, one (and only one) of the requisites can be designated as the main one; it may not necessarily be the data type to which we are drawing the form. But the behavior of the form will depend on the data type of the main attribute. In addition to changing the behavior of the form, there is a change in the context of the form module. Along with the methods and properties of the form, methods and properties of the object, which is the value of the main attribute, become available in it. It is important that the forms of the "Free form" type do not have the main attribute. In this case, the behavior of the form is determined only by the user's settings. Consider the questions about the main details.

Question 10.05 for exam 1C: Platform Professional. What is the main requisite of the form?

1. Defines the data source for the entire form
2. Defines standard features platforms for working with form data of the type specified for the main attribute
3. To provide the ability to programmatically access the object's attributes from the local context of the form
4. Provides visualization of object details on the form dialog
5. 2 and 3 are true
6. 1 and 2 are true

The correct answer is sixth, see above.

Question 10.06 of exam 1C: Platform Professional. What are the form details for?

1. To describe the composition of the data that is displayed, edited or stored in the form
2. To display and edit data in a form
3. 1 and 2 are true

The third answer is both.

Question 10.07 of exam 1C: Platform Professional. To assign the main attribute to an arbitrary controlled form ...

1. you need to check the box "Main attribute" in the properties of the form attribute
2. you need to fill in the "Data" property of the form by selecting the required form attribute

The correct answer is the second one:

Question 10.08 of exam 1C: Platform Professional. To assign the main attribute to an arbitrary regular form ...

1. the form needs to be made the main one, the main attribute is determined automatically
2. you need to check the box "Main attribute" in the properties of the form attribute
3. you need to enter the "Edit" menu, the "Main attribute" item and select the desired value
4. you need to fill in the "Data" property of the form by selecting the required form attribute

The fourth correct answer is:

The main props are highlighted in bold:

Question 10.09 of exam 1C: Professional on the platform. If you have one main form attribute, can you add one more main attribute?

1. It's impossible
2. It is possible by assigning an appropriate value to the property of the form attribute
3. It is possible only programmatically, when referring to the "Form" object
4. It is possible by adding another value to the corresponding property of the form

The correct answer is the first, the main requisite is strictly one, since the connection with the object must be unambiguous.

Question 10.113 of exam 1C: Professional on the platform. Which of the requisites of the form shown in the figure is the main one?

1. ListCurrencies
2. ReferenceObject
3. Directory forms do not have the main requisite
4. For directory forms, all the requisites are basic.

The second correct answer is the bold one.

General props in 1C 8.3 is a platform metadata object that allows you to use one attribute for many configuration objects (directories, documents, charts of accounts, etc.). The object was created mainly to facilitate the developer's work and data separation.

The general details were originally implemented in version 1C 7.7, but the developers did not immediately include it in the platform of version 8. The mechanism of general details was introduced by the 1C developers only in release 8.2.14.

It is very convenient to add general requisites so as not to change standard objects in the configuration, I often use them along with.

After adding a general attribute, it can be used in queries and displayed on the form of objects - outwardly, it is no different from ordinary props.

The only limitation of general details is that they cannot be used in.

Let's consider the basic settings and properties of common attributes, which are different from other configuration objects:

Composition- a list of objects to which the common attribute will be used, the setting resembles the setting of an exchange plan.

Get 267 1C video tutorials for free:

Auto use- the setting determines whether a common attribute will be used for those objects for which the "Automatic" mode of use is specified.

Data sharing- we will consider this setting separately.

Separation of data in 1C using a common props

Data sharing- a mechanism similar to the mechanism. However, the performance of this mechanism is more efficient and easier to configure.

The mechanism allows you to customize the display of only elements that the user can see. For example, you can delimit all objects (documents, directories, etc.) where a certain organization is established.

Setting up data separation using general 1C details

For setting in the general attribute, you must specify the data separation - Divide... Immediately after clicking, the system will offer to create default accounting parameters:

In this case, it will be necessary to specify the session parameters at the start of the system, how to do this, with an example it was described in the article.

This completes the setup - the user will only have access to the information that is specified in the selected session parameters.

An example of using common props

Let's analyze the setting of the general props in 1C 8.3 using the example of a frame configuration and props Organization:

There are 3 documents in the system where it is necessary to indicate the Organization variable: this is the Receipt Invoice, Expense Invoice, Salary Accrual.

The setup is simple:

1. Create a new General Attribute, specify the type - DirectoryLink.Organization.
2. In the composition we place for our documents - Use.

That's it, the setup is over!

Let's see the result:

The system displays the general attribute "as its own": in requests, and in the form attributes, and in other places. This is the magic! 🙂

General props 1C 8.3 is not added