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 "Using modal windows V this mode prohibited." In this case, the execution of the program code stops.
This article shows the mechanism for changing the program code, using the example of a question to the user when the modal mode.
Periodically, during development software product, there is a need to ask the user about the actions being performed. For example, with automatic filling 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.)
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, click right click on the "Configuration" item and select "Properties" from the drop-down menu:
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.
Implemented in version 8.3.3.641.
1C:Enterprise uses modal windows in situations where the user is required to enter information, without which further execution of the algorithm is impossible. In this case, the entire rest of the program interface is completely blocked, and the execution of the program code stops until the user closes the modal window.
With the advent of the web client and the transition of 1C:Enterprise to mobile platforms, modal windows turned out to be a source of a large number of inconveniences and problems, often insoluble.
As a rule, "desktop" browsers, better or worse, support modal windows and open them in a new browser window as a "pop-up window":
But due to the fact that pop-up window technology is massively used on the Internet for advertising, almost all browsers have pop-up windows disabled by default. In the vast majority of cases, without changing this browser setting, the web client will not work.
Another problem is that mobile browsers They don't support modal windows at all. And so that 1C:Enterprise could work in them, a special mechanism was implemented in the web client. This is a rather complex mechanism and, unfortunately, does not cover all necessary situations. As a result, configurations on iPads, for example, are difficult to maintain.
In such a situation, the option of operating the 1C:Enterprise interface without using modal windows eliminates all the problems listed above.
At the same time, there is no abandonment of the functionality that was previously provided by modal windows. But this functionality is implemented by other technologies that do not interfere with the operation of 1C:Enterprise in browsers.
In the new mode of operation of the interface, the window, which previously would have been modal, is drawn within the parent window, and in the same way blocks the rest of the web client interface:
As a result:
- no new browser windows are opened, which improves the performance and stability of the web client;
- In many cases additional customization browser becomes unnecessary, since 1C:Enterprise no longer uses pop-up windows;
- any configuration using the web client can work on iPad and other mobile devices.
Naturally, miracles don’t happen, and a new operating mode cannot be turned on “with a wave.” magic wand". A change in the logic for working with new, blocking windows is required. But the good news is that these changes are simple, and it is possible to monitor all “suspicious” places in the program. The platform implements a special mechanism that allows you to check at the development stage that the entire configuration uses new mechanisms and will work without modal windows.
The need to change the logic of working with such windows is due to the fact that the new mode of operation of the interface provides modality only for the user. However, for the developer, the execution of the program code does not stop when the blocking window is displayed.
This means that the algorithm, which was previously one whole, will now have to be divided into two parts. One, which ends with the opening of a blocking window, and the second, which will be executed when the user closes this window. So that the system knows where to continue executing the program code, the blocking window is given the name of the procedure that should be executed when the user closes this window.
The essence of these changes is easiest to see with an example. An old procedure that opened a modal window and processed the data it received might look like this:
In a new version for the form FormTextInput (which will open in a blocking window) you need to set the property Window Opening Mode in meaning BlockAllInterface . This will provide a modality for the user:
And the program code, instead of one procedure, as before, will contain two procedures:
In the first procedure, open the form. At the same time, in last parameter we pass it the location of the second procedure that will be executed after the user closes the window. In this case, this procedure is located in the same module, but in general it can be located in another one.
When the user enters data and closes the form, it will be processed in the second procedure we specified, into which we simply transferred the “old” code that processes the received data.
In addition to the forms that the developer can open in modal mode (at will), there are built-in language methods that always, regardless of the developer's desire, open modal forms for entering or selecting data. For example, the method EnterValue() .
Using such methods in modeless mode is even easier. For all such methods, the platform has duplicate methods, when calling them you must also indicate the location of the procedure that will be executed after the user closes the window.
For example, below is shown using the old method EnterValue() and its new backup method ShowInputValue() :
It must be said that, in addition to the listed cases, some platform mechanisms also use modal windows to interact with the user. And this no longer depends on the actions of the developer.
Therefore, all such system dialogs of the platform have also been transferred to a modeless mode of operation.
It is planned to gradually phase out the use of modal windows in application solutions. Therefore, for compatibility with application solutions written earlier, the platform retains the ability to work in the old version of the interface, using modal windows.
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 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.
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 = Dialog.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 a 1C user can work in a browser, he has to be forced to allow these windows, taught him all the intricacies of how 1C and browsers work, and generally overloaded 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 mobile app 1C also didn’t quite make friends 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 1C platform, we have 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 be executed 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
Procedure ProcessingPeriodSelection(Period,Parameters) Export
If Period<>Undefined Then
Items.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.
Loading...
