Form module context

Each module is connected to other configuration parts. This relationship is referred to as a module context.

The module context defines the assortment of objects, variables, procedures, and functions available when the module is executed.

Since further we will talk about the handler that you created in the form module, let us discuss the content of the form module context in detail.

A form module context consists of:

Local form module context
Module form attributes
Properties and methods of the ManagedForm 1C:Enterprise script object
Properties and methods of the form extension that is defined by the type of the object whose data is stored in the main form attribute
Global context, including nonglobal common modules and exported functions and procedures of global common modules
Exported variables, procedures, and functions of the managed application module

Now let us discuss all the listed items in detail.

Local form module context.

The local form module context consists of variables, procedures, and functions declared in that module.

For example, inside a form module, you can call the GetTotal() procedure that is declared in this module using its name (listing 5.2).

Listing 5.2. Form module
```
&AtClient
Procedure Command1()
    GetTotal();
EndProcedure

&AtServerNoContext
    Procedure GetTotal()
    ...
EndProcedure
```
Also, inside a form module, you can directly address the InternalVariable variable that is declared in this module using its name (listing 5.3).

Listing 5.3. Form module
```
&AtClient
Var InternalVariable;

&AtClient
Procedure Command1()
    InternalVariable = 3;
EndProcedure
```
Module form attributes.

For example, if a form has an InternalAttribute attribute (fig. 5.8), you can directly address it using its name (listing 5.4).

Fig. 5.8. Form attribute: InternalAttribute

Listing 5.4. Form module
```
&AtClient
Procedure Command1()
    InternalAttribute = 3;
EndProcedure  
```
Properties and methods of the ManagedForm object.

Properties and methods of the ManagedForm 1C:Enterprise script object are described in the Syntax Assistant, in section Interface(managed) / Managed form / ManagedForm (fig. 5.9).

Fig. 5.9. Managed form properties and methods in the Syntax Assistant

You can address them directly using their names. For example, you can define a form header (listing 5.5).

Listing 5.5. Form module
```
&AtClient
Procedure Command1()
    Title = "New form title";
EndProcedure
```
Or you can close a form (listing 5.6).

Listing 5.6. Form module
```
&AtClient
Procedure Command1()
    Close();
EndProcedure
```
Properties and methods of the form extension that is defined by the type of the object whose data is stored in the main form attribute.

One of the form attributes can be the default one. It is displayed in bold in the attribute list. Normally the default form attribute contains the data of the object displayed in the form. For example, in a catalog form, the default attribute stores the data of the CatalogObject.<name> object (fig. 5.10).

Fig. 5.10. Default form attribute

And in a document form, the default attribute stores the data of the DocumentObject.<name> object (fig. 5.11).

Fig. 5.11. Default form attribute

Here we should clarify why the default attribute type is displayed in brackets in the list of attributes: (DocumentObject.Document1). This is because it is not the real attribute type. In this case, the real type is FormDataStructure (fig. 5.12).

Fig. 5.12. Object type of the default form attribute

But FormDataStructure is a universal type that can store data of various application objects. So to provide a clear description of the application object displayed in the form, the Type column of the editor shows the type of the object whose data is stored in this attribute instead of the actual form attribute type (FormDataStructure). And this "fake" type is displayed in the brackets.

The type of the object whose data is stored in the default form attribute affects some form behavior specifics.

For example, if the default form attribute stores document data, the user is prompted to confirm saving and posting of this document when the form is closed. And if the default form attribute stores catalog data, the platform does not display that prompt when the form is closed.

Depending on the type of the object whose data is stored in the default attribute, the context of the ManagedForm script object includes the context of the respective extension.

For example, if the default attribute is CatalogObject.<name>, the properties and methods of the Managed form extension for catalogs 1C:Enterprise script object is available in the form module (in the Syntax Assistant, see section Interface (managed) / Managed form / Managed form extension for catalogs, fig. 5.13).

Fig. 5.13. Object descriptions in Syntax Assistant

And if the default attribute is DynamicList (fig. 5.14), the properties and methods of the Managed form extension for dynamic lists 1C:Enterprise script object are available in the form module (in the Syntax Assistant, see section Interface (managed) / Managed form / Managed form extension for dynamic lists, fig. 5.15).

Fig. 5.14. Default form attribute

Fig. 5.15. Object descriptions in Syntax Assistant

So in a form module where the default attribute stores document data (fig. 5.16), you can call the AutoTime property of Managed form extension for documents (listing 5.7).

Fig. 5.16. Default form attribute

Listing 5.7. Form module
```
&AtClient
Procedure Command1()
    AutoTime = AutoTimeMode.First;
EndProcedure
```
Or you can save the document using the Write() method of Managed form extension for documents (listing 5.8).

Listing 5.8. Form module
```
&AtClient
Procedure Command1()
    Write(DocumentWriteMode.Posting);
EndProcedure
```
Global context, including nonglobal common modules and exported functions and procedures of global common modules.

In a form module, you can get the system date by calling the CurrentDate() built-in function (listing 5.9).

Listing 5.9. Form module
```
&AtClient
Procedure Command1()
    Message(CurrentDate());
EndProcedure
```
Or you can get the history of user actions by calling the UserWorkHistory property of the global context (listing 5.10).

Listing 5.10. Form module
```
&AtClient
Procedure Command1()
    History = UserWorkHistory.Get();
EndProcedure
```
If a global common module (for example, DataExchange) defines the GetNumberPrefix() export procedure (listing 5.11), you can call it using its name in the form module (listing 5.12).

Listing 5.11. Global common module
```
Function GetNumberPrefix() Export
    Return Constants.NumberPrefix.Get();
EndFunction 
```
Listing 5.12. Form module
```
&AtClient
Procedure Command1(Prefix)
    Prefix = GetNumberPrefix();
EndProcedure
```
If such common module is nonglobal (for example, DocumentProcessing), when you call a procedure you have to specify the procedure name after the module name, separated by a dot (.), see listing 5.13.

Listing 5.13. Form module
```
&AtClient
Procedure QuantityOnChange(Item)
    DocumentProcessing.CalculateTotal(TabularSectionRow);
EndProcedure
```
The latter method is better because, unlike global modules, nonglobal common modules are not compiled at the system startup. Instead, they are compiled when they are called.

Of course, it is important to ensure that the procedure directive in the form module (&AtClient, &AtServer, and so on) matches the properties of the common module (Client (managed application), Server, and so on).
Exported variables, procedures, and functions of the managed application module.

If a TestMessage() export procedure is defined in an application module (listing 5.14), you can call it using its name in the form module (listing 5.15).

Listing 5.14. Application module
```
Procedure TestMessage() Export
    Message("Test message");
EndProcedure
```
Listing 5.15. Form module
```
&AtClient
Procedure Command1()
    TestMessage();
EndProcedure
```

Next page: A form as a script object