In the 1C platform version 8.3, a new mode of program operation has appeared - without using modality. More precisely, 2 new modes have appeared: without using modality and using modality, but with a warning. And the old mode of operation is indicated as using the modality.
What does this all mean? In early versions of the platform, we used various modal windows and didn’t think much about it. For example, you need to display a warning to the user, or you need to ask a question, or enter some value, or select a file. These are all modal windows.
What does modal mean? This means that when this window is called, it overlaps all other windows, that is, it is displayed at the very top and blocks work with other windows until work with this window is completed. In addition to blocking windows, code execution stops exactly at the point where this window is called and code execution continues only after such a window is closed. From the point where execution stopped. I will illustrate the call to the modal window using the example of calling the period selection form:
&OnClient
StandardProcessing = False;
If Dialog.Edit() Then //Call the modal form. Code execution will continue only after the form is closed.
Elements.Services.CurrentData.StartDate = Dialog.Period.StartDate;
Elements.Services.CurrentData.EndDate = Dialogue.Period.EndDate;
endIf;
End of Procedure
As we can see, one procedure is enough to process the call to the period selection modal window.
Why are modal windows bad? Now let's figure out why 1C decided to abandon the use of modal windows. Well, first of all, this is a consequence of the fact that the 1C platform can be used not only in its usual form - as a desktop application, but can also be launched in a browser and can be launched as a mobile application.
The problem with browsers is the following. The window modality in them is implemented using pop-up separate browser windows. They are supported by almost all browsers, but due to the frequent use of such windows for advertising, almost all browser developers struggle with them and disable the use of such windows by default. As a result, in order to ensure that the 1C user can work in the browser, it is necessary to force him to allow these windows, to dedicate him to all the intricacies of the work of 1C and browsers, and generally overload him with unnecessary information.
A separate nuance with browsers for tablet computers and browsers for phones. In most cases, these browsers do not support pop-ups. The interfaces (monitors and input devices) of such devices with pop-up windows are not compatible.
And finally, the 1C mobile application is also not entirely friendly with modal windows.
Hence the conclusion: Do not use modal windows. What should I use instead? Instead, you need to use the same windows, but without the modality mode. In the new platform, 1C has also developed such a mode for each window. It is implemented as a separate method for each dialog. This mode allows you to open a window, but not stop the execution of program code. Technically, browsers implement this as a pseudo window that appears inside the parent window, but overlaps it. The fact that the code continues to execute after the window is opened means that you will not be able to immediately receive the values selected in it after the code for calling the window. They haven't been chosen yet. Therefore, obtaining and processing these values is carried out in a separate procedure, which is called when closing such a window, and this procedure is specified when calling the window opening method. Let's look at the same period selection window as an example.
&OnClient
Service ProcedureStartDateStartSelection(Element, SelectionData, StandardProcessing)
StandardProcessing = False;
Dialog = NewEditingDialogStandardPeriod();
StandardPeriod = New StandardPeriod();
StartDate = Items.Services.CurrentData.StartDate;
EndDate = Items.Services.CurrentData.EndDate;
StandardPeriod.StartDate = StartDate;
StandardPeriod.EndDate = EndDate;
Dialog.Period = StandardPeriod;
Alert Description = New Alert Description("Period Selection Processing", ThisForm);
Dialog.Show(DescriptionAlerts)
End of Procedure
&OnClient
ProcedurePeriodSelection Processing(Period,Parameters) Export
If Period<>Undefined Then
Elements.Services.CurrentData.StartDate = Period.StartDate;
Elements.Services.CurrentData.EndDate = Period.EndDate;
endIf;
End of Procedure
As we can see, instead of Edit(), Show() is called. And processing the selection event is already in another procedure.
So, we figured out how to do without modality. Now let's figure out why we need the mode of using a modality with a warning. In essence, this is a transitional regime. When you have not yet managed to convert your entire configuration to a mode without using a modality, but are already striving for this. And every time you call a modal window, the program will give you a warning that it is not advisable to call modal windows in this mode.
Well, let’s abandon modality and master new technologies for 1C work in browsers and mobile computers.
In the configuration properties on the 1C:Enterprise 8.3 platform there is a Mode for using modality. If the value of this field is "Do not use", then when you try to open a modal window, the platform will display the message "The use of modal windows in this mode is prohibited." In this case, the execution of the program code stops.
This article shows the mechanism for changing program code, using the example of a question to the user when the modal mode is disabled.
From time to time, when developing a software product, there is a need to ask the user about the actions being performed. For example, when automatically filling out tabular parts. When, before refilling the PM, it is necessary to ask the user about the need to do this. And depending on his answer, the PM will be cleared and refilled, or not.
The question portion of the code might look something like this:
If PM. Quantity()< >0 Then Answer = Question(" // This line will display a modal window with a question and code execution will stop until the user answers If Answer = DialogReturnCode. No Then Return ; EndIf ; // User agrees to continue PM. Clear() ; EndIf ; // Perform further actions // The program will go here if the PM was empty or the user answered positively to the question about refilling Perform Further Actions () ;When modal mode is disabled, an error will occur in the question line of this code and further execution will be interrupted. This will happen because the Question function uses a modal window.
In this situation, you must use the ShowQuestion procedure. This procedure does not wait for the user's response to complete. But the first parameter of this procedure is the description of the alert, which is used to track the user's response.
How the previously written code will change:
// It is necessary to fill in the PM data // Checking the PM for fullness If PM. Quantity()< >0 Then // PM is not empty, you need to ask the user about refilling ShowQuestion(New DescriptionAlerts(" Refill TCCompletion" , ThisObject, AdditionalParameters) , " The PM will be refilled. Continue ?", Dialogue ModeQuestion. YesNo) ; // This line will display a question window, but the code will not stop executing Otherwise // The program will go here if the PM was empty Perform Further Actions() ; EndIf ; // The program will get here in any case, whether the PM was empty or not // (unless, of course, there was an error in the previous code) . . . // Export procedure in the same module // Called after the user answers the question& On the Client Procedure Refill TCCompletion (Response Result, Additional Parameters) Export If Response Result = Dialogue Return Code. No Then // The user refused to continue Return ; EndIf ; // Perform further actions // The program will go here if the PM was not empty and the user answered positively to the question about refilling PM. Clear() ; Perform Further Actions() ; End of ProcedureThus, since the program will not stop when the ShowQuestion procedure is executed, it is necessary to carefully handle all events
When solving this problem, further actions can occur when two events occur:
1. If the PM was empty
2. If the PM was not empty and the user responded positively to the question, refill
And, accordingly, since the program does not stop waiting for the user’s response, the calling of these events has to be distributed in different parts of the code.
Therefore, as a rule, all executable methods that need to be performed after checking the PM for completeness are placed in a separate procedure.
A similar mechanism is used for similar user interaction functions (SelectValue, SelectFromList, etc.)
The article will discuss the main reasons for abandoning modality in the 1C:Enterprise platform and the main methods for converting code sections to a new asynchronous model.
Applicability
The article discusses the asynchronous model for constructing business logic, the added platform “1C:Enterprise” edition 8.3. The information presented is relevant for current platform releases.
Refusal to use modal windows in the 1C:Enterprise 8.3 platform
When developing a configuration on the 1C:Enterprise 8 platform, the need periodically arises to pause the program until the user makes a decision or performs some action.
For example, when clicking on the fill tabular section button, the user should be asked whether the tabular section needs to be cleared so that previously entered data is not lost.
This behavior can be achieved, for example, by the following code:
&OnClient
Procedure Fill in Products(Team )
Answer = Question (“The table part will be cleared. Continue?”, Dialogue ModeQuestion.YesNo);
If Answer = Dialogue Return Code.Yes Then
//filling algorithm
EndIf ;
End of Procedure
As a result of this code fragment, the execution of the program code will be suspended, a question will be displayed on the screen, the application interface except for the dialogue with the question will become unavailable, the system waits for the user to make a decision, and code execution will continue only after the question is answered.
Opening modal windows by calling the OpenModal() method also causes pauses in code execution and blocking of the interface.
When working with the configuration in web client mode through a browser, in this case a new window will open - a pop-up window that will block not only the current tab, but also the entire browser interface, including other open windows and tabs.
Pop-up windows on the Internet are often used to maliciously distribute unwanted advertisements, which is why browsers contain pop-up blocking features.
In this case, to work with 1C:Enterprise 8 configurations through a browser, you must disable pop-up blocking.
Problems also arise when working on mobile devices. For example, modal windows are not supported on iPad.
To solve these problems, you should use blocking windows instead of modal ones. For the user, visually everything looks the same: the window blocks the web client interface.
However, the blocking window is “drawn” on top of the main window, and only the current browser tab in which the configuration is open is blocked, allowing you to switch to other tabs, since modal browser windows are not used.
Thus, pop-up windows do not open in the browser and work through the web client on mobile devices is ensured.
The root element of the configuration has a property “Modality mode”, which determines whether modal windows can be opened in the configuration.
If the “Use” option is selected, then modal windows can be opened. If the “Do not use” option is selected, then modal windows are not allowed. When you try to call a method that opens a modal window, the system displays an error message:
With this value of the “Modality usage mode” property, only blocking windows are allowed.
If the “Use with warnings” option is selected, then when modal windows are opened, the following text is displayed in the message window:
This work option can be used as an intermediate one when reworking the configuration in order to abandon the use of modal windows.
The main difference between blocking windows and modal windows is that opening a blocking window does not pause code execution.
Therefore, developers will have to rewrite the program code that uses modal windows to take this feature into account.
The code needs to be divided into two parts:
- opening a blocking window;
- processing user selection.
The code fragment given at the beginning of the article needs to be rewritten as follows:
&OnClient
Procedure Fill in Products(Team )
Alert = New DescriptionAlerts(, ThisObject );
Dialogue ModeQuestion.YesNo);
End of Procedure
&OnClient
Procedure (Result, Extra options) Export
If Result = Dialogue Return Code.Yes Then
//filling algorithm
EndIf ;
End of Procedure
After executing the ShowQuestion() procedure, the system does not stop, waiting for the user's response, code execution continues.
The user will be able to make a choice only after the entire procedure is completed. In this case, the export procedure FillItemsQuestionComplete() will be called. We passed its name to the constructor of the DescriptionAlerts object.
The procedure that will be called after making a selection can be located in a form module, a command module, or a general non-global module.
In the example considered, the called procedure is located in a managed form module, so we passed in the ThisObject parameter.
Let's consider calling a procedure located in a common module. To do this, add a new common module Notification Processing, set the “Client (managed application)” flag for it, and do not set the “Global” flag. Let's place the procedure Fill in Products Question Completion () in this module.
Then the fill command handler will look like this:
&OnClient
Procedure Fill in Products(Team )
Alert = New DescriptionAlerts(“Fill in Products Question Completion”,
ProcessingAlerts);
Question Text = “The tabular part will be cleared. Continue?" ;
ShowQuestion (Alert , Question Text , Dialogue ModeQuestion.YesNo);
End of Procedure
After calling any method that opens a blocking window, the procedure must exit, and the code that runs next should be placed in a procedure that will be called after the window is closed.
To transfer context (auxiliary data, certain parameters, variable values) from the procedure that opens the modal window to the procedure called when it is closed, a third optional parameter of the object constructor is provided: DescriptionAlerts – Additional Parameters.
This object (of any type) will be passed to the procedure described in Alert Description as the last parameter.
Using the example of the code section discussed above, this can be done like this:
&OnClient
Procedure Fill in Products(Team )
Parameter1 = 0 ;
Parameter2 = 0 ;
List of Parameters= New Structure (“Parameter1, Parameter2″, Parameter1, Parameter2);
Alert = New DescriptionAlerts(“Fill in Products Question Completion”, ThisObject ,
List of Parameters);
ShowQuestion (Alert, “The table part will be cleared. Continue?”,
Dialogue ModeQuestion.YesNo);
End of Procedure
&OnClient
Procedure Fill inProductsQuestionCompletion(Result , Extra options) Export
If Result = Dialogue Return Code.Yes Then
//analyze Additional Parameters.Parameter1
//analyze Additional Parameters.Parameter2
EndIf ;
End of Procedure
If you need to pass only one value, then you can not use the structure, but assign this value to the Additional Parameters parameter of the constructor of the DescriptionAlerts object.
Let's look at a few examples of working with blocking windows.
Task 1: Open another form
From the document form, by clicking on the “Open parameters” button, you need to open a form on which there are two checkboxes Parameter1 and Parameter2, which the user must set. After closing the form, display the parameter values in the message line.
We create a general form “ParametersForm”, on which we place the details Parameter1 and Parameter2, as well as the CloseForm command:
The command handler looks like this:
The command handler looks like this: &OnClient
Procedure CloseForm (Command)
List of Parameters= New Structure ( “Parameter1, Parameter2”, Parameter1 , Parameter2 );
Close ( List of Parameters); End of Procedure
For the form, set the WindowOpenMode property to “Block entire interface”:
On the document form we place the OpenParameters command, the handler of which is described as follows:
&OnClient
Procedure OpenOptions(Team )
Alert = New DescriptionAlerts(“Open Options Finish”, ThisObject );
OpenForm ( “GeneralForm.FormParameters”, , , , , , Notification);
End of Procedure
&OnClient
Procedure OpenOptionsComplete(Result , Extra options) Export
If TypeValue (Result) = Type (“Structure”) Then
For each KeyValue From Result Loop
Message = New Message to User;
Message.Text = “Key: “” ” + KeyValue.Key + “””, value = ”
+
KeyValue.Value;
Message.Report();
EndCycle ;
EndIf ;
End of Procedure
In user mode, running the configuration under the web client, we get the following results:
To enlarge, click on the image.
The window opening mode can also be specified in the last parameter of the OpenForm procedure.
&OnClient
Procedure OpenOptions(Team )
Alert = New DescriptionAlerts(“Open Options Finish”, ThisObject );
OpenForm ( “GeneralForm.FormParameters”, , , , , , Alert
FormWindowOpenMode.LockEntireInterface);
End of Procedure
Task 2. Question when closing the form
When closing a processing window, ask the user whether he really wants to close the window.
This problem can be solved using the following code located in the processing form module:
&OnClient
Perem Need to Close the Form;
&OnClient
Procedure Before Closing (Failure, StandardProcessing)
If not Need to Close the Form= True Then
Refuse = True ;
Alert = New DescriptionAlerts(“Before ClosingCompletion”, ThisObject );
ShowQuestion (Alert, “Are you sure you want to close the window?”,
Dialogue ModeQuestion.YesNo);
EndIf ;
End of Procedure
&OnClient
Procedure Before Closing Completion(Result , Extra options) Export
If Result = Dialogue Return Code.Yes Then
Need to Close the Form= True ;
close();
Otherwise
Need to Close the Form= Undefined ;
EndIf ;
End of Procedure
In the BeforeClosing form procedure, the user is asked a question, the Refusal flag is set to True, and the closing of the form is cancelled.
After an affirmative answer to the question, the variable Need toCloseForm is set to True, and the form is closed again.
Task 3: Entering a Numeric Value
When you click on the button on the processing form, open a standard number entry dialog.
To do this, you need to use the ShowNumberInput() method instead of EnterNumber(), which opens a blocking window instead of a modal one.
&OnClient
Procedure Entering Numbers (Command)
Alert = New DescriptionAlerts(“EnterNumberComplete”, ThisObject );
ShowEnterNumbers(Alert, 0, “Enter quantity”, 15, 3);
End of Procedure
&OnClient
Procedure EnteringNumbersCompleting(Result , Extra options) Export
Message = New Message to User;
Message.Text = “You have entered a quantity” + Result;
Message.Report();
EndIf ;
End of Procedure
After closing the number entry window, a procedure will be called, the first parameter of which will be the entered number or the Undefined value if the user refused to enter.
Task 4. Choosing a color
When you click on the button on the processing form, using the standard color selection dialog, the user specifies the required color. Set this color for the background of the clicked button.
Add the SelectColor command to the form with the following handler:
&OnClient
Procedure Color Selection (Command)
Color Selection Dialog= New Color Selection Dialog;
Alert = New DescriptionAlerts(“Color SelectionComplete”, ThisObject );
Color Selection Dialog. Show(Alert);
End of Procedure
&OnClient
Procedure ChoiceColorsCompletion(Result , Extra options) Export
If NOT Result = Undefined Then
Elements.Color Selection.Background Color= Result ;
EndIf ;
End of Procedure
For Color Selection Dialog objects (as well as Standard Period Editing Dialog, Format Line Constructor, Regular Task Schedule Dialog, Font Selection Dialog), the Show() method opens a blocking window.
After closing the window, a procedure will be called, the first parameter of which will be passed the selected value (color, font, etc.) or the Undefined value if the user has refused the choice.
It should be noted that the FileSelectionDialog object does not have a Show() method, unlike color or font selection dialogs, since the implementation of these dialogs is significantly different.
To use the file selection dialog on the web client, you must first enable the file extension.
Dialogs implemented through the file extension do not create the same operational problems as modal browser windows, so opening blocking windows for the FileSelectionDialog object was not implemented.
In conclusion, we note that starting with release 8.3.10, support for modal windows has been discontinued in the web client. In this case, if a modal method is called in the configuration, an exception is generated. Also, support for interface mode has been discontinued in the web client In separate windows. In addition, in both the thin and web clients it is no longer possible to open a form in a separate window (when working in the Bookmarks interface mode). Such drastic steps made it possible to abandon the interface mode, which is no longer supported by all modern browsers.
What practical conclusion can be drawn from this information? And the conclusion is quite simple - if for some reason there are still modal calls in your configuration, then in these places in the web client a window with an error message will be displayed. I would like to warn against trying to “Google” some quick solution to this problem, because... Most of the advice comes down to this recipe: in the configurator at the configuration level, set the “Modality usage mode” property to “Use”. Naturally, at the moment, this will not work only because modern browsers themselves no longer support modal calls.
And you have only two ways to solve the problem described above:
- Update the platform to release 8.3.10+ (8.3.11), set the “Compatibility Mode” configuration property to “Do not use” and rewrite code fragments that use modal methods to an asynchronous business logic model
- Recommend your clients to use older browsers that still supported modal calls (Mozilla Firefox versions 37 and below, Chrome versions below 37, etc.).
By the way, starting with release 8.3.11, Microsoft Internet Explorer web browsers versions 8 and 9 are no longer supported.
We have dealt with web browsers in the light of modality, now it’s time to clarify the situation with other clients.
Starting with version 8.3.5, the Modality Usage Mode property in thin and thick clients is respected only if the /EnableCheckModal command line option is specified. This parameter is automatically inserted into the command line only when the application is launched from the configurator. If this parameter is not specified, then no exceptions are generated and corresponding warnings are not shown. Those. in practice, when using a thick and thin client, no fundamental change in operation is observed when using the modal mode - modal calls will work the same as they worked before, without producing any warnings, as in the web client.
To dot the i's, note that starting with version 8.3.9, the thick client ignores the configuration property “Mode of using synchronous calls to platform extensions and external components”, while the corresponding synchronous methods work without generating exceptions and displaying warnings. The specified ignored property was added in version 8.3.5 to support asynchronous work with external components, cryptography and extensions for working with files in the Google Chrome web browser. It is clear that this has nothing to do with the thick client, and therefore “quietly” ignoring this property simply eliminated unnecessary checks for the use of synchronous methods when using the configuration.
By the way! Due to the fact that the platform is confidently moving towards the web, with version 8.3.8 the developers have introduced certain restrictions on the program code that is associated with the logic for closing a form or application, executed in thick and thin clients. Be sure to read our article covering this nuance in detail. In addition, in the course “Professional development of interfaces and forms in 1C: Enterprise 8.3”, there is a chapter dedicated to the abandonment of modality, and you can glean a lot of useful and relevant information on this topic.
Colleagues, there are two things that you can read endlessly: the VKontakte feed and the list of changes in the next release of the platform, so let’s sum up the final results;)
In the process of considering examples that allow you to move from elements of a synchronous model to an asynchronous one, you probably already noticed that in the general case there is more program code. The more code there is, the more the complexity of its further maintenance and debugging increases.
In addition, the amount of code will increase even more if we use more dialogs during the development process. Therefore, in the process of developing application solutions focused on working in a web client, you need to remember the work paradigm that is currently used in modern web applications. Therefore, if your configuration has a lot of interactive dialogs with the user and warnings, then it makes sense to reconsider this functionality in favor of some other approaches to organizing user interaction.
Instead of a conclusion
Our cycle “First steps in 1C development” has come to an end. If you read it in its entirety, then most likely you have already noticed how the platform has been developing by leaps and bounds lately. The material in this series was written relatively recently, but we were forced to seriously update it, because... Even in such a short period of time, a lot of new important functionality and changes have appeared. Such major changes can be somewhat perplexing for a 1C programmer if he has not grown and developed professionally with the platform all this time.
On specialized Internet resources you can often read requests from novice programmers and their more mature colleagues to recommend materials that would help them understand the extensive and sometimes seemingly endless capabilities of the 1C platform. We, traditionally, recommend that you pay attention to our programming courses
The introduction of the new interface of the 1C 8.3 platform - "taxi" - led to the fact that users and programmers were faced with the following error: "The use of modal windows in this mode is prohibited."
Rice. 1
The developers of the 1C technology platform strive to follow global trends by bringing the software in line with international standards. The latter inevitably leads to a single interface, close to web pages.
Modal and pop-up windows, being a sign of bad taste, have long been considered unacceptable in software development. The need to work “in one window” is firmly ingrained in the minds of users.
The developers of the 1C platform made an attempt to involve developers of application solutions in working in a “new way”. With the introduction of the new "taxi" interface, they added a new feature to the new platform - "modality mode".
Quick fix
In the absence of time, if you need to quickly resolve the problem, you can resort to a fairly simple, but not very correct solution - you just need to change the modality mode in the configuration properties.To do this, log into the system in configurator mode and open the configuration:
After that, by right-clicking on the configuration root, open the context menu and select “Properties”:
Rice. 3
In the configuration properties that open, in the tabs, find “Modality usage mode”, select “Use” in it:
Rice. 4
Save and apply your changes by pressing the "F7" key.
