Using global variables in modules

This article describes the standards that apply to global variables. All of the listed recommendations are mandatory unless noted otherwise.

1. In most scenarios, we recommend that you do not use global variables and use other 1C:Enterprise script tools instead. Since monitoring the visibility (usage) areas of such variables is tricky, they often might cause issues that cannot be easily located.

Examples of incorrect variable usages and exceptions to this rule are provided later in this article. The variable declaration format is described in the Module structure article.

2. This section contains examples of incorrect variable usages in object modules (such as catalog, document, record set, data processor, or report modules).

2.1. We recommend that you use the AdditionalProperties object property for passing parameters between event subscription handlers and for passing parameters from external script to object module event handlers.

Incorrect:

Variable FileConversion Export;
Procedure BeforeWrite(Cancel)

  If FileConversion Then
  ...

EndProcedure

// script that calls the procedure
FileObject.FileConversion = True;
FileObject.Write();

Correct:

Procedure BeforeWrite(Cancel)

  If AdditionalProperties.Property("FileConversion") Then 
  ...

EndProcedure

// script that calls the procedure
FileObject.AdditionalProperties.Insert("FileConversion", True);
FileObject.Write();

At the same time, it is a good practice to use nonexport object module variables, which are not available from external script, for passing internal parameters between object module event handlers.

Example:

Variable PreviousCompanyValue; // value of the "company" attribute before writing the object to the database
Procedure BeforeWrite(Cancel)
  PreviousCompanyValue = ...; // use a query to retrieve the value before writing the object to the database
EndProcedure
Procedure OnWrite(Cancel)
  If PreviousCompanyValue <> Company Then
    // process the attribute value change during the writing
    ...
  EndIf;
EndProcedure

2.2. We recommend that you use string constants for processing return codes (errors) in the module logic.

Incorrect:

Variable NoErrors,
Error_FillCheckProcessing, // occurs if the fill check processing returns Cancel
Error_WriteObject, // occurs if an exception is raised while the object is being written
Error_LockObject, // occurs during the attempt to lock the object
Procedure RunRecalculation()
  ...
  Result = ProcessDocuments(...);
  If Result = Error_WriteObject Then
    ...
  ElsIf Result = Error_LockObject Then
    ...
  ElsIf ...
EndProcedure
...
////////////////////////////////////////////////////////////////////////////////
// MODULE INITIALIZATON
NoErrors = 1;
Error_FillCheckProcessing = 2;
Error_WriteObject = 3;
Error_LockObject = 4;

Correct:

Procedure RunRecalculation()
  ...
  Result = ProcessDocuments(...);
  If Result = "ErrorWriteObject" Then
    ...
  ElsIf Результат = "ErrorLockObject" Then
    ...
  ElsIf ...
EndProcedure

2.3. We recommend that you use modules with reusable return values for caching values that have long calculation time and are frequently used in procedures or functions during server calls.

Scenarios, where you cannot return the result of a calculation performed in an export function due to security reasons, are an exception to this rule. Use local module variables for storing such values.

3. This section contains examples of incorrect variable usages in form modules.

3.1. We recommend that you use modules with reusable return values for caching values that have long calculation time and are frequently used in procedures or functions.

Do not cache static data or data that can be calculated quickly. In particular, do not cache values of predefined items or enumerations in client variables of form modules. Use the PredefinedValue method for getting them on the client.

3.2. Use the following entities for storing intermediate results and for passing them between form procedures and functions:

  • Procedure and function parameters for passing results through the call stack in a single procedure or function call context.
  • Form attributes for storing intermediate results between different calls from the client (note that the values of server form module variables are not preserved between the calls from the client).

Scenarios, where client form variables are used for storing intermediate results of form idle handlers, external event handlers, or client form item event handlers, are an exception to this rule.
Example:

&AtClient
Variable PictureNumber; // the counter used for naming files while scanning multiple images
...
&AtClient
Procedure ExternalEvent(Source, Event, Data)
 If Source = "TWAIN" And Event = "ImageAcquired" Then
  If PictureNumber = Undefined Then
   PictureNumber = 1;
  EndIf; 
  PictureNumber = PictureNumber + 1;
  // Saving the scanned document to the file named PictureNumber
  // ...
 EndIf; 
EndProcedure

4. Use variables of managed and ordinary applications for storing "client session parameters". For details, see Using session parameters.

Next page: Creating and changing metadata objects


Be the first to know tips & tricks on business application development!

A confirmation e-mail has been sent to the e-mail address you provided .

Click the link in the e-mail to confirm and activate the subscription.