Chrome the use of modal windows in this mode is prohibited. What to do if "the use of modal windows in this mode is prohibited." Correct solution of the problem

If in the process of completing the lessons you have such an error, it is very easy to fix it.

Return to the configurator and select the "Configuration" -> "Open configuration" menu item:

In the window that opens, click right click on the "Configuration" item and select the "Properties" item from the drop-down menu:

A window with configuration properties will open (on the right):

Scroll to the very bottom and find the "Mode of using modality" item there:

Set its value to "Use":

Attention! Please note that if you are using a 1C platform that is different from the one that we downloaded in the first lesson (later version), then you will also have the field "Mode of using synchronous calls ...". It also needs to be set to "Use".

Finally, select the "Configuration" -> "Save Configuration" menu item:

Ready! Now the error will no longer occur.

The explanations below are for those who are interested in what we have done.

We have enabled the mode of using the modality in our configuration. By default, this mode is disabled and it does not allow us to use such commands as EnterNumber, EnterString, EnterDate, OpenValue.

The point is that these commands are modal. Calling them leads to the fact that a window appears in front of the user (for example, for entering information), which blocks the ability to work with the program until the window is closed.

And since the presence of such windows is extremely undesirable when working with 1C through a web browser, when developing new configurations, the modality mode is disabled by default.

We can safely include it, as we write educational examples that are not designed for work on the Internet.

The article will consider the main reasons for abandoning modality in the 1C: Enterprise platform and the main methods of converting code sections to a new asynchronous model.

Applicability

The article discusses the asynchronous model of building business logic, the added platform "1C: Enterprise" version 8.3. The information provided 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, there is a need to suspend the operation of the program from time to time until the user makes a decision or performs any action.

For example, when clicking on the button to fill in the tabular section, the user should be asked whether it is necessary to clear the tabular section so that the previously entered data will not be lost.

This behavior can be provided, for example, by the following code:

& OnClient
Procedure FillProducts(Command )
Answer = Question (“The table section will be cleared. Continue?”, Dialogue Mode Question Yes No);
If Answer = Dialog Return Code.Yes Then
// filling algorithm
EndIf;
End of Procedure

As a result of the work of this piece of code, the execution of the program code will be suspended, a question is displayed on the screen, the application interface, in addition to the dialog with the question, becomes inaccessible, the system is waiting for a decision by the user, the code execution will continue only after the answer to the question.

Also, opening modal windows by calling the OpenModal () method leads to the suspension of 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 the rest open windows and tabs.

Pop-ups on the Internet are often used to maliciously distribute unwanted advertisements, which is why browsers include pop-up blocking features.

In this case, to work with 1C: Enterprise 8 configurations through a browser, it is necessary to disable blocking of pop-up windows.

Problems also arise when working on mobile devices... For example, modals 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" over 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 the modal browser windows are not used in this case.

Thus, pop-up windows in the browser do not open and work through the web client on mobile devices is ensured.

The root configuration element has a property “Modality use 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 you select the "Do not use" option, then modals are invalid. When trying to call a method that opens a modal window, the system displays an error message:

With this value of the "Modality use mode" property, only blocking windows are allowed.

If the option “Use with warnings” is selected, then when modal windows are opened, the following text is displayed in the message window:

This variant of work can be used as an intermediate one when reworking the configuration in order to refuse the use of modal windows.

The main difference between blocking and modal windows is that opening a blocking window does not pause code execution.

Therefore, developers will have to rewrite the code that uses modals with this feature in mind.

The code needs to be split into two parts:

• opening a blocking window;
• handling user selection.

The code snippet at the beginning of the article needs to be rewritten as follows:

& OnClient
Procedure FillProducts(Command )
Alert = New Description Alerts(, ThisObject);

Dialogue Mode Question Yes No);
End of Procedure
& OnClient
Procedure (Result, Extra options) Export
If Result = Dialog Return Code.Yes Then
// filling algorithm
EndIf;
End of Procedure

After executing the ShowQuestion () procedure, the system does not stop, waiting for the user to respond, the code continues to execute.

The user will be able to make a choice only after completing the entire procedure. This will call the export procedure FillProductsQuestionCompletion (). We passed its name to the Alert Description object constructor.

The procedure that will be called after making a selection can be located in a form module, a command module, a common non-global module.

In the above example, the called procedure is located in a managed form module, so we passed thisObject into the parameter.

Consider a call to a procedure located in a common module. To do this, add a new common module ProcessingNotifications, set the flag “Client (managed application)” for it, and do not set the flag “Global”. Place the FillProductsQuestionCompletion () procedure in this module.

Then the fill command handler will look like this:

& OnClient
Procedure FillProducts(Command )
Alert = New Description Alerts("FillProductsQuestionFinishing",
Processing Notifications);
QuestionText = “The table section will be cleared. Proceed?" ;
Show Question (Alert, Question Text, Dialogue Mode Question Yes No);
End of Procedure

After calling any method that opens the blocking window, the procedure must complete, and the code executed further should be located in the procedure that will be called after the window is closed.

To pass the context (auxiliary data, some parameters, variable values) from the procedure that opens the modal window to the procedure that is called when it is closed, the third optional parameter of the object constructor DescriptionNotifications - AdditionalParameters is provided.

This object (of any type) will be passed to the procedure described in AlertDescription as the last parameter.

Using the example of the above code section, this can be done like this:

& OnClient
Procedure FillProducts(Command )
Parameter1 = 0;
Parameter2 = 0;
Parameter List= New Structure (“Parameter1, Parameter2 ″, Parameter1, Parameter2);
Alert = New Description Alerts("FillProductsQuestionFinishing", ThisObject,
Parameter List);
ShowQuestion (Alert, “The table section will be cleared. Continue?”,
Dialogue Mode Question Yes No);
End of Procedure
& OnClient
Procedure FillProductsQuestionFinishing(Result , Extra options) Export
If Result = Dialog Return Code.Yes Then
// parse AdditionalParameters.Parameter1
// parse AdditionalParameters.Parameter2
EndIf;
End of Procedure

If you need to pass only one value, then the structure can not be used, but assign this value to the AdditionalParameters parameter of the object constructor DescriptionAlerts.

Let's look at some examples of working with blocking windows.

Task 1. Opening another form

From the document form, by clicking on the "Open parameters" button, you need to open the form, on which there are two check boxes Parameter1 and Parameter2, which must be set by the user. After the form is closed, output the parameter values ​​to the message line.

Create a general form “Parameters Form”, on which we place the parameters 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)
Parameter List= New Structure ( "Parameter1, Parameter2", Parameter1, Parameter2);
Close ( Parameter List); End of Procedure

For the form, set the WindowOpening Mode property to “Lock the entire interface”:

On the document form, place the OpenParameters command, the handler of which is described as follows:

& OnClient
Procedure OpenParameters(Command )
Alert = New Description Alerts("OpenParametersCompletion", ThisObject);
OpenForm ( "GeneralForm.ParameterForm",,,,,, Notification);
End of Procedure
& OnClient
Procedure OpenParametersCompletion(Result , Extra options) Export
If TypeZnch (Result) = Type ("Structure") Then
For each Key Value From Result Cycle
Message = New Message to User;
Message.Text = “Key:“ ” "+ KeyValue.Key +" "", value = "
+ Key Value. Value;
Message.Inform();
End of Cycle;
EndIf;
End of Procedure

In user mode, running the configuration under the web client, we get the following work results:

Click on the image to enlarge.

The window opening mode can also be specified in the last parameter of the OpenForm procedure.

& OnClient
Procedure OpenParameters(Command )
Alert = New Description Alerts("OpenParametersCompletion", ThisObject);
OpenForm ( "GeneralForm.ParameterForm",,,,,, Alert,
ModeOpenWindowForms.LockAllInterface);
End of Procedure

Task 2. Question when closing the form

When closing the processing window, ask the user whether he really wants to close the window.

This task can be solved using the following code located in the processing form module:

& OnClient
Change NeedCloseForm;
& OnClient
BeforeClose Procedure (Disclaimer, Standard Processing)
If not NeedCloseForm= True Then
Refusal = True;
Alert = New Description Alerts("BeforeCloseCompletion", ThisObject);
ShowQuestion (Alert, “Are you sure you want to close the window?”,
Dialogue Mode Question Yes No);
EndIf;
End of Procedure
& OnClient
Procedure BeforeCloseCompletion(Result , Extra options) Export
If Result = Dialog Return Code.Yes Then
NeedCloseForm= True;
Close ();
Otherwise
NeedCloseForm= Undefined;
EndIf;
End of Procedure

In the procedure Before Closing the form, the user is asked a question, the Refuse flag is set to True, and the form is closed.

After an affirmative answer to the question, the variable MustCloseForm is set to True, the form is closed again.

Task 3. Entering a numerical value

When you click on the button on the processing form, open the standard dialog for entering a number.

To do this, use the ShowNumberEnter () method instead ofNumberEnter (), which opens a blocking window instead of a modal one.

& OnClient
Number Entry Procedure (Command)
Alert = New Description Alerts("EnterNumberCompletion", ThisObject);
ShowEnterNumbers(Announcement, 0, “Enter the amount”, 15, 3);
End of Procedure
& OnClient
Procedure EnterNumbersCompletion(Result , Extra options) Export

Message = New Message to User;
Message.Text = “You have entered the quantity” + Result;
Message.Inform();
EndIf;
End of Procedure

After closing the window for entering a number, a procedure will be called, the first parameter of which will be passed the entered number or the Undefined value if the user refused to enter.

Task 4. Choosing a color

When clicking on the button on the processing form using the standard color selection dialog, the user specifies the required color. Set this color to the background of the button you press.

Add the SelectColor command to the form with the following handler:

& OnClient
Color Select Procedure (Command)
DialogueSelectColors= New DialogueSelectColors;
Alert = New Description Alerts("SelectColorCompletion", ThisObject);
DialogueSelect Colors. Show (Notification);
End of Procedure
& OnClient
Procedure ChoiceColorsCompletion(Result , Extra options) Export
If NOT Result = Undefined Then
Elements.Color.ColorBackground= Result;
EndIf;
End of Procedure

For ColorSelectDialogue objects (as well as StandardPeriodEdit Dialogue, FormatString Constructor, RegularJobScheduleDialogue, FontSelect Dialogue), the Show () method opens a blocking window.

After the window is closed, 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 canceled the selection.

Note that the FileSelectDialog object does not have a Show () method, unlike the 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 connect the file extension.

Dialogs implemented through the file extension do not create such problems in operation as modal windows of browsers, therefore, opening blocking windows for the FileChoiceDialog object was not implemented.

In conclusion, we note that since 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 thrown. Also, in the web client, support for the interface mode is discontinued. In separate windows... In addition, it is no longer possible to open a form in a separate window in both the thin and the web client (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, modal calls still exist in your configuration, then a window with an error message will be displayed in these places in the web client. I would like to warn against attempts to "google" any quick solution to this problem, because the bulk of the advice comes down to the following recipe: in the configurator at the configuration level, set the "Modality use mode" property to the "Use" value. Naturally, in this moment, it won't work just because modern browsers no longer support modal calls.

And you have only two ways how to solve the problem described above:

1. Upgrade the platform to release 8.3.10+ (8.3.11), set the configuration property "Compatibility mode" to "Do not use" and rewrite code fragments that use modal methods to an asynchronous model for building business logic
2. Recommend your clients to use outdated browsers where modal calls were still supported ( Mozilla Firefox version 37 and below, Chrome below version 37, etc.).

By the way, starting with release 8.3.11, Microsoft web browsers are no longer supported Internet Explorer versions 8 and 9.

With web browsers in the light of modality, we figured out, now it's time to clarify the situation with the rest of the clients.

Starting from version 8.3.5, the property "Modality usage mode" in thin and thick clients is taken into account only if the / EnableCheckModal command line parameter is specified. This parameter is automatically substituted into command line only when starting the application from the configurator. If this parameter is not specified, then no exceptions are generated and the corresponding warnings are not shown. Those. in practice, in the case of using a thick and thin client, no fundamental change in work is observed when using the modality mode - modal calls will work the same way as they did before, without generating 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 throwing exceptions and displaying warnings. The specified ignored property was added in revision 8.3.5 to support asynchronous work with external components, cryptography and extensions for working with files in a web browser Google chrome... It is clear that this has nothing to do with the fat client, and therefore “silent” ignoring of this property simply eliminated unnecessary checks on the use of synchronous methods when using configuration.

By the way! Due to the fact that the platform is confidently moving towards the web, since version 8.3.8, the developers have introduced certain restrictions on the program code that is associated with the logic of 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 devoted to the rejection of modality, and you can get a lot of useful and relevant information on this topic.

Colleagues, there are two things that can be read endlessly: the VKontakte feed and the list of changes in the next release of the platform, so let's summarize;)

In the process of looking at examples that allow you to move from the elements of a synchronous model to an asynchronous model, you probably already noticed that in the general case there is more code. The more code, 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 dialogues during the development process. Therefore, in the process of developing application solutions focused on working in a web client, you need to remember about the paradigm of work that is currently used in modern web applications. Therefore, if your configuration has a lot of interactive dialogs with the user, issued warnings, then it makes sense to revise this functionality in favor of some other approaches in organizing user interaction.

Instead of a conclusion

So our cycle "First steps in development on 1C" has come to an end. If you have read it in its entirety, then most likely you have already noticed with what leaps and bounds the platform has been developing lately. The material of this cycle was written relatively recently, but we had to seriously update it, because even in such a short time, a lot of new important functionality and changes. Such large changes may somewhat perplex the 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 advise them on materials that would help them understand the vast and sometimes seemingly endless possibilities of the 1C platform. We, by tradition, recommend that you pay your attention to our programming courses

  14
 To force the enterprise to start in a Normal or Managed application, the following keys are used: / RunModeOrdinaryApplication starts the thick client in normal mode, despite the configuration settings and ...   3
 It is necessary that users cannot change the interface configured for them! Solution: To disable it, you need to remove the "Save user data" right in the access rights of the root configuration element. ...   2
 In the current work, the user usually opens several objects. It can be a document, reference book, report, etc. In the previous interface, there was no problem to quickly find an open object and update it for ...   2
 In the last article: Installing an address classifier (KLADR) in 1C, I told you what Kladr is and how to load it into 1C regular forms (8.0-8.2). In this article I will show you how to load the Address Classifier (KLADR) in ...   2
 Often when developing a certain configuration, users want to attach photos to a directory item and have them stored in the database. In this article I will tell you how to connect construction objects to the reference book ...

In the 1C platform version 8.3 appeared new regime work of the program - without the use of modality. More precisely, 2 new modes appeared: without using modality and using modality, but with a warning. And the old mode of operation is denoted how to use modality.

What does this all mean? In the early versions of the platform, we used various modal windows and didn't really think 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 brought to the very top and blocks work with other windows until the end of work with this window. In addition to blocking windows, the execution of the code stops exactly at the place where this window is called and the continuation of the code execution is carried out only after closing such a window. From where the execution stopped. I will illustrate the call of the modal window by the example of calling the form for selecting the period:

& OnClient

StandardProcessing = False;

If Dialog.Edit () Then // Call the modal form. The continuation of the code execution will occur only after the form is closed.
Elements.Services.CurrentData.StartDate = Dialog.Period.StartDate;
Elements.Services.CurrentData.EndDate = Dialogue.Period.EndDate;
EndIf;

End of Procedure

Why are modals 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 - in the form of a desktop application, but can also be launched in a browser and can be launched in the form of a mobile application.

The problem with browsers is as follows. The modality of the windows 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 the ability of the 1c user to work in the browser, you have to force him to allow these windows, devote himself to all the subtleties of 1c and browsers and generally overload 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. Interfaces (monitors and input devices) of such devices with pop-up windows are not compatible.

And finally mobile app 1C also did not quite make friends with modal windows.

Hence the conclusion: do not use modals. And what to use instead of them? Instead, you need to use the same windows, but without the modality mode. In the new platform, 1C also developed such a mode for each window. It is implemented as a separate method for each dialog. This mode allows you to call the window, but not stop the execution of the program code. Technically in browsers, this is implemented 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 cannot get the values ​​selected in it immediately after the window calling code. They have not been selected yet. Therefore, the receipt and processing of these values ​​is carried out in a separate procedure that is called when such a window is closed and this procedure is specified when the method for opening the window is called. Let's look at the example of the same window for selecting a period.

& OnClient
Service ProcedureStartDateSelectionStart (Item, SelectionData, StandardProcessing)

StandardProcessing = False;

Dialog = New EditStandardPeriod Dialogue ();
StandardPeriod = New StandardPeriod ();

StartDate = Items.Services.CurrentData.StartDate;
EndDate = Items.Services.CurrentData.EndDate;

StandardPeriod.StartDate = StartDate;
StandardPeriod.EndDate = EndDate;
Dialogue.Period = StandardPeriod;

AlertDescription = New AlertDescription ("PeriodSelectionProcessing", ThisForm);

Dialogue.Show (Alert Description)

End of Procedure

& OnClient
Procedure for ProcessingSelecting a Period (Period, Parameters) Export

If Period<>Undefined Then

Items.Services.CurrentData.StartDate = Period.StartDate;
Items.Services.CurrentData.EndDate = Period.EndDate;

EndIf;

End of Procedure

So, we figured out how to do without modality. Now let's figure out what the mode of using the modality with a warning is for. In fact, this is such a transitional regime. When you have not yet had time to redo your entire configuration for a mode without using modality, but you are already striving for this. And every time a modal window is called, the program will give you a warning that it is undesirable to call modal windows in this mode.

Well, we abandon modality and master new technologies for 1C work in browsers and mobile computers.