Why do I get the error "Using synchronous methods on the client is prohibited"? When you need it

Print (Ctrl + P)

Working with files in asynchronous mode is present only on the side of the client application. In general, it is recommended to use synchronous methods for working on the server side and asynchronous methods for working on the client side.
Let's consider an example of working with files in the asynchronous technique: deleting all files in the temporary files directory. For a synchronous technique, such an action will look like this:

& OnClient
Procedure Delete (Command)
DeleteFiles (TemporaryFiles Directory (), GetMaskAllClientFiles ());

End of Procedure
The asynchronous technique will look different:

& OnClient
Procedure Delete (Command)
Callback \u003d New Alert Description (“GetTemporaryFilesDirectoryCompletion”, ThisObject, “DeleteError”, ThisObject);
StartGettingDirectoryTemporaryFiles (Callback);
End of Procedure
& OnClient
Procedure GetTempFilesDirectoryCompletion (TempFilesDirectoryName, AdditionalParameters) Export
Callback \u003d New Alert Description (“DeleteCompletion”, ThisObject, “FileError”, ThisObject);
StartDeletingFiles (Callback, TemporaryFilesDirectoryName, GetMaskAllClientFiles ());
End of Procedure
& OnClient
Procedure DeleteCompletion (AdditionalParameters) Export
Report (“Deletion completed successfully”);
End of Procedure
& OnClient
Procedure FileError (ErrorInformation, StandardProcessing, AdditionalParameters) Export
Report (“An error was encountered while executing a file operation:” + BriefEnterprise (ErrorInformation));
End of Procedure

At first, it should be noted that almost all file operations have become asynchronous. Even simple actions like getting a directory of temporary files. And the need to get such a directory leads to the first asynchronous call. Then the actual deletion of all files is called. And processing the completion of the deletion requires a second handler, which should contain the actions that should occur after all files in the temp directory are deleted. IN this example this is the issuance of an operation completion message.
If an error occurs during the execution of file operations, control will be transferred to the handler FileError ()... In it, you can correctly handle the current situation.

Working with files in the web client

Working with files in the web client has a number of features:
1. Without installing extensions, in any web browser, only the GetFile () and StartPlaceFile () methods are available. The PlaceFile () method is not supported when working with a web browser Google chrome and if the use of modal methods is prohibited for configuration (configuration property Modality use mode, see here).
2. When installing the extension for working with files in all web browsers, except for Google Chrome, both synchronous and asynchronous methods of working with files are available (synchronization or asynchrony depends on the configuration property Modality use mode),
3. For the Google Chrome web browser, only the asynchronous file extension is available. Synchronous operation is not supported.
4. The file extension does not support HTTPS using a client certificate.
Note 1. For correct work Microsoft web browser file extensions Internet Explorer it is recommended to use
Microsoft Core XML Services (MSXML) libraries 4.0 or 6.0.
Note 2. The extension for working with files for the Microsoft Internet Explorer web browser is installed in the% APPDATA% \\ 1C \\ 1СEWebExt \\ FileSystemExtIE directory

Why do I get the error "Using synchronous methods on the client is prohibited"?

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

Return to the configurator and select the "Configuration" -\u003e "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 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" -\u003e "Save Configuration" menu item:

Done! 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 commands such 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.

"Using modal windows prohibited in this mode "- this error now begins to bother users and 1C programmers with the arrival of the new interface of the 1C 8.3 platform -" ".

The developers of the 1C technological platform keep up with the times, standardizing their solution to world development standards software... All standards in one way or another are reduced to a single interface, close to web pages.

Modal and pop-up windows are considered bad form and have long ceased to be normal in software development. Users are accustomed to working "in one window".

Especially often we see a modality error in the following 1C methods:

  • Question;
  • Warning;
  • OpenValue.

With the release of the new taxi interface, the developers of the 1C 8 platform made the right decision - to try to retrain the developers of applied solutions in a new way. They have included in the new platform a feature called "modality usage mode".

Quick fix for the problem

If you don't have time to figure it out and you need to quickly solve a problem, we offer a simple, but not entirely correct solution. To quickly fix the error, it is enough to change the modality mode in the configuration properties.

To do this, go to the system in the mode, open the configuration:

In the open configuration, call the context menu by right-clicking on the configuration root and selecting "Properties":

Get 267 1C video tutorials for free:

The configuration properties will open, where in the basement there is a property of interest to us - "Modality use mode", select the "Use" mode:

After that, save and apply the changes by pressing the "F7" key.

Correct solution of the problem

The correct way to solve this problem is to modify the configuration or external processing for new requirements.

Warning, question, dialog boxes and other modals - all this needs to be rewritten in a new way.

The built-in operators that called modals need to be replaced with duplicate functions.

For instance:

  • Warning - Show Warning;
  • Question - Show Question (in detail -);
  • - Show Input Numbers.

At the same time, a specialized object appeared - Notification Description.

Replacement example:

String \u003d ""; EnterString (String, "Enter string value") Report ("You entered" + String);

Must be replaced with:

String \u003d ""; Alert Description \u003d New Alert Description ( "TestInputString", ThisForm); ShowInputString (Alert Description, String, "Enter string value") ;

At the same time, add a similar procedure on the client, which will work when the value is entered by the user:

& OnClient Procedure TestInputString (ReceivedValue, PassedParameters) Export Report ("you entered" + String); End of Procedure

Forms that are developed inside the configuration open in the same way. It is enough to replace the "OpenFormModal" method with "OpenForm", specifying the description of the notification and the new procedure required for it.

To close access to the called form by the opening form, it is enough to specify in the "WindowOpening Mode" property the "Lock owner window" value in the form property:

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(Team )
Answer \u003d Question (“The table section will be cleared. Continue?”, Dialogue Mode Question Yes No);
If Answer \u003d Dialog Return Code.YesThen
// filling algorithm
EndIf;
End of Procedure

As a result of the work of this piece of code, the execution will be suspended program code, 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 question is answered.

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 other 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 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 the option “Do not use” is selected, then modals are not allowed. 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 stop using 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 to take this feature into account.

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(Team )
Alert \u003d New Description Alerts(, ThisObject);

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

After executing the ShowQuestion () procedure, the system does not stop, waiting for the user's answer, the code execution continues.

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 the 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 general Alert Processing module, set the “Client (managed application)” flag for it, and leave the “Global” flag unchecked. Place the FillProductsQuestionCompletion () procedure in this module.

Then the fill command handler will look like this:

& OnClient
Procedure FillProducts(Team )
Alert \u003d New Description Alerts("FillProductsQuestionFinishing",
Processing Alerts);
QuestionText \u003d “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 transfer 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(Team )
Parameter1 \u003d 0;
Parameter2 \u003d 0;
Parameter List\u003d New Structure (“Parameter1, Parameter2 ″, Parameter1, Parameter2);
Alert \u003d 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 \u003d Dialog Return Code.YesThen
// 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 \u200b\u200bto the message line.

Create a general form “ParameterForm”, 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\u003d 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(Team )
Alert \u003d New Description Alerts("OpenParametersCompletion", ThisObject);
OpenForm ( "GeneralForm.ParameterForm",,,,,, Notification);
End of Procedure
& OnClient
Procedure OpenParametersCompletion(Result, Extra options) Export
If TypeZnch (Result) \u003d Type ("Structure") Then
For each Key Value From Result Cycle
Message \u003d New Message to User;
Message.Text \u003d “Key:“ ” "+ KeyValue.Key +" "", value \u003d "
+ 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(Team )
Alert \u003d 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\u003d True Then
Refusal \u003d True;
Alert \u003d 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 \u003d Dialog Return Code.YesThen
NeedCloseForm\u003d True;
Close ();
Otherwise
NeedCloseForm\u003d Undefined;
EndIf;
End of Procedure

In the procedure Before Form Closing, 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 NeedCloseForm 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 \u003d New Description Alerts("EnterNumberCompletion", ThisObject);
ShowEnterNumbers(Announcement, 0, “Enter the amount”, 15, 3);
End of Procedure
& OnClient
Procedure EnterNumbersCompletion(Result, Extra options) Export

Message \u003d New Message to User;
Message.Text \u003d “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 desired color. Set this color for the background of the button being pressed.

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

& OnClient
Color Select Procedure (Command)
DialogueSelectColors\u003d New DialogueSelectColors;
Alert \u003d New Description Alerts("SelectColorCompletion", ThisObject);
Dialogue Select Colors.Show (Notification);
End of Procedure
& OnClient
Procedure ChoiceColorsCompletion(Result, Extra options) Export
If NOT Result \u003d Undefined Then
Elements.Color.ColorBackground\u003d 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.

It should be noted 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 browser windows, 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 the 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" some fast decision 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, at the moment, this will not work only 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 legacy 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, web browsers Microsoft Internet Explorer versions 8 and 9 are no longer supported.

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 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. This ignored property was added in 8.3.5 to support asynchronous work with external components, cryptography and file extensions in the Google Chrome web browser. 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, 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 you can 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 general 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 to organizing user interaction.

Instead of a conclusion

So our cycle "First steps in development on 1C" has come to an end. If you 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

If you are an active user of the 1C software product, this is great. The program is really good, it allows you to perform multiple tasks quickly and with the highest quality. Everything would be fine if she did not occasionally shock her with frightening messages about the errors that had occurred. It is good if such errors were previously encountered by you personally or by those who work next to you and can clearly explain on the fingers how to fix the problem, as well as explain why it occurred.

The problem is corrected after changing the settings or the 1C code.

Such information content will allow the 1C program to work again, as well as in the future to avoid serious blunders that provoke problems.

Algorithm for correcting errors in 1C

There is also such an error in 1C "The use of synchronous methods on the client is prohibited." You should not panic even when it occurs, it is enough to navigate in the sequence of your actions, having studied the valuable recommendations of experienced users.

Making changes to the program settings

If you tried to call the context method in the 1C program, but instead of the expected subsequent actions, to which you are already accustomed, a message suddenly popped up stating that the use of synchronous methods on the client is prohibited, you should not panic, let's try to figure out this software failure.

Initially, click on the "Configurator" line. After that, in the open context menu go to the last line "Properties", click on it. Now a window will open in which you can independently make some changes to the settings, including adjustments and in the program operation mode.

Find the line "Mode of using synchronous calls of extensions and external components" among the offered modes. Note what value is set for this mode. It is important that the Use option is selected. If you see something else, click on the selection box and select this option.

Now close all open windows and try all the desired actions again. The likelihood that you will succeed is high.

Code change

Unfortunately, it is not always possible to fix the error "The use of synchronous methods on the client is prohibited" after making changes to the program settings. Sometimes you have to carry out more important measures. In particular, make changes to the program code. Experienced users recommend using the asynchronous login method if the synchronous one suddenly becomes disabled.

Open the program code. Leave the name of the procedure (Procedure OpenLiFile1 ()) and its end (EndProcedure) unchanged, and change the body of the procedure radically.

You only have to write three lines:

Alert \u003d New AlertDescription ("WriteMore", ThisObject);
TextQuestion \u003d "Write?";
ShowQuestion (Notification, TextQuestion, DialogueQuestion Mode.Yes No);

If you absolutely don't understand anything about this, it doesn't matter, just copy and paste between the name of the procedure and its final line. We really believe that when you perform such actions, everything will fall into place and the program will work again, allowing you to perform all actions at a professional high level.