The introduction of the new interface of the 1C 8.3 platform - "taxi" - led to the fact that users and programmers encountered an error with the following content: "Using modal windows V this mode forbidden".
Rice. 1
The developers of the 1C technology platform strive to follow global trends by bringing software in accordance 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 application solutions to work in a new way. With the introduction of the new "taxi" interface, they complemented the new platform new feature- "mode using modality".
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 context menu, select "Properties":
Rice. 3
In the configuration properties that open, in the tabs, find “Modality use mode”, in it select “Use”:
Rice. 4
Save and apply your changes by pressing the "F7" key.
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 part button, the user should be asked whether he or she needs to clear tabular part 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 dialog 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 the rest open windows and tabs.
Pop-up windows on the Internet are often used for malicious distribution unwanted advertising, 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 the module controlled form, so we passed in the ThisObject parameter.
Let's consider calling a procedure located in a common module. To do this, let's add a new one common module Processing Notifications, 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 last parameter procedures OpenForm.
&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
Failure = 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 standard dialogue When choosing a color, 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 fast decision 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, in this moment, this will not work only because modern browsers 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
- Encourage your customers to use legacy browsers that still supported modal calls (Mozilla Firefox versions 37 and below, Chrome version below 37, etc.).
By the way, starting with release 8.3.11, Microsoft Internet web browsers are no longer supported Explorer versions 8 and 9.
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 substituted in command line only when launching the application 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 all the “i”s, we note that starting from edition 8.3.9, the configuration property “Mode of using synchronous calls of platform extensions and external components” is ignored in the thick client, 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 a web browser Google Chrome. 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 learn a lot of useful and up-to-date 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. 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
Dialog boxes, which we are quite accustomed to when working with all kinds of systems and, in particular, in 1C, can appear when performing various actions, requiring the user to enter some data, for example, certain value, select a file, answer a question, or simply issue a warning. They are also called modal.
Without a response to the request of such a window, it is impossible to continue working in the program. The window blocks the interface, blocks the work of other windows, and at the same time, the execution of program codes will also stop at the place where the dialog was called - the program waits for the completion of the action with it.
Dialogs usually do not cause problems in the thin and thick client launch mode, but problems may arise when working with the web client. This is due to the fact that the same system elements on the Internet are used as advertising media, and users often disable their display in their browser settings. Accordingly, their work is blocked in a program running through a web browser. Therefore, when working with 1C via a web client or on a mobile platform, you must not forget to perform additional settings browser and remember that mobile browser Doesn't support pop-up messages at all.
How to resolve the error in 1C: “The use of modal windows in this mode is prohibited”
This error began to appear after 1C switched to the new interface of the 1C 8.3 platform - “Taxi”. This is due to the fact that the developers included work with windows in it, but without the modality mode.
Fig.1
Let's open information base in the “Configurator” mode and look at the properties of our configuration by right-clicking and selecting the “Properties” command. Scrolling down the line below, we see the “Compatibility” section, where the mode parameter we are interested in is located and the options are listed - “Use / Use with a warning / Do not use.”
Fig.2
After this, you need to save and update the configuration changes. The error we are talking about appears when the checkbox is set to not use the modality mode. This opportunity appeared starting with platform 8.3.3.721, released in September 2013. That is, users running older versions of the platform do not need to opt out of the modality. In other versions, so that the error window does not appear, you can simply set it to “Use”.
In our example, the warning option is set. Of course, in the future, developers will improve the configuration to use other functions that bypass modal windows. But today, the mode from our example is exactly what the developer uses during the transition, when not the entire configuration has yet been converted to a modeless mode. Therefore, the program will also issue messages about the prohibition of windows with modal characteristics.
Fig.3
Applications that are used through the web client, on the iPad, in the cloud, for example, on "1cfresh.com", do not use this mode. All new configurations use a modeless interface mode.
Refusal of modality
The developers of the 1C program, supporting global trends, are trying to bring the program interface closer to web samples and bring it to a single standard, thereby giving users the opportunity to work in one window with a familiar “external” interface.
Therefore (and in order to alleviate the problems described above) it was decided to eliminate pop-up dialogs without limiting the functionality of the solutions. In this case, messages in the new operating mode of the program appear within the parent window, and not, as before, in the modal window. Although it still blocks the entire interface.
That is, the innovation eliminates the need for additional browser settings, stabilizes the web client and improves its performance. Also, since there is now no need to open pop-ups, any configuration with these changes can be used on any device.
If you encounter such an error while completing the lessons, it is very easy to fix it.
Return to the configurator and select the menu item "Configuration" -> "Open configuration":
In the window that opens, right-click on the “Configuration” item and select “Properties” from the menu that opens:
A window with configuration properties will open (right):
Scroll to the very bottom and find the “Modality mode” item there:
Set its value to "Use":
Attention! Please note that if you are using a 1C platform different from the one we downloaded in the first lesson (later version), then you will also have the “Mode for using synchronous calls...” field. It also needs to be set to "Use".
Finally, select the menu item "Configuration" -> "Save configuration":
Ready! Now the error will no longer occur.
Explanations below - for those who are interested in what we did.
We have enabled modality mode in our configuration. By default, this mode is disabled and this does not allow us to use commands such as EnterNumber, EnterString, EnterDate, OpenValue.
The fact is that these commands are modal. Calling them results in a window appearing 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 turned off by default.
We can safely include it, since we are writing educational examples that are not designed for working on the Internet.
The Syntax Helper for these commands states that if the configuration property Mode of UseModalities installed in Do not use, then you should use other commands in your program code, such as ShowQuestion(), ShowWarning(), ShowNumberInput():
To work with these situations, the 1C 8.3 program provides a new system object “Description of Alerts”, which is used to describe the call of a program module procedure when any expected event occurs, such as closing a form or a non-modal dialog:
This is an inside look at the problem for those who want to get to the root cause. First of all, for 1C programmers. In this situation, how can ordinary users fix the error without working on the program code? There is a very simple method.
Instructions for correcting the error for ordinary users
Step 1: Finish:
Step 2. Return to start menu to run the configuration. Select the “Configuration” menu item:
Step 3. Open the “Configurator”: on the top panel we find the “Configuration” button, and in the proposed list select the “Open configuration” menu:
Step 4. Place the cursor on Configuration and right button use the mouse to call up the context menu, in which we select the “Properties” item:
Step 5. Open the “Properties” form:
Step 6. Find the line “Mode of using modality” (at the bottom of the list):
By default in the 1C 8.3 program the value is “Do not use”. Convert the value “Do not use” to the value “Use”:
Result:
If the error “The use of modal windows in this mode is prohibited” in 1C 8.3 has gone away, then you can continue working. This is usually what happens.
But if the modality error in 1C remains after performing all these steps, then you should contact the programmers who service and support your 1C program.
How to work in the “Taxi” interface, how to customize the workplace, customizing the Favorites navigation bar, how to perform full-text search, techniques for working with logs, the “select” button in documents, sending links to documents, verification and other features in new interface - you can learn all this from our video:
More details about how to correctly and quickly organize navigation through the 1C 8.3 program using the new TAXI interface, about new opportunities in using familiar tools, such as a built-in calculator, calendar, file comparison, transferring links to documents to colleagues are discussed in our course ““
Please rate this article:
Loading...
