1c managed forms to ask the user a question. How to use showquestion in form handler before post

Introduction

Why is it even worth abandoning modality and, for example, replacing Question with ShowQuestion? The thing is that more than a year ago 1C nicknames declared “war” on modal windows. The only exceptions are those who have a self-written configuration, which will not be worked on an iPad, in service mode or using a web client. And if you have regular Accounting 3.0 and you are not going to give an accountant access to the database via an iPad, you will still have to replace all modal methods with non-modal ones, because sooner or later the “Modality Use Mode” will become “Do Not Use”!

What do 1C specialists think about this proposed issue? To get started, you can look at the topic “Question in the BeforeClose form handler”:

The peculiarity of the dialogue with the user in this (and many other) handlers is that, depending on the user’s reaction, a decision is made: to continue further actions or to abandon them. To do this, use the Reject procedure parameter. With one response from the user, we refuse to continue (Rejection = True). If the user responds differently, we continue further actions.

In this case, the difficulty lies in the fact that we will find out the user’s response after we leave the context of this handler. In the procedure that processes the alert. And the Rejection parameter must be set in this particular handler.

Therefore, we act in two steps:

For the first time, we unconditionally cancel further actions (Rejection = True) and display the question to the user;

In the notification handler, depending on the user's reaction, we either programmatically close the form again or do nothing.

The problem is that the BeforeClose handler will be executed twice. And to distinguish the first execution from the second (when the user's answer is already known), we use the client variable In ProgressClose as a flag.

On the first pass, its value is False, which means that you need to abandon the closure and ask a question. In the second pass, its value is True, which means that the question does not need to be asked:

&OnClient Variation In ProgressClosing; &OnClient Procedure BeforeClose(Failure, StandardProcessing) If Closing Is Not Performed Then Failure=True; ShowQuestion(New AlertDescription("BeforeClosingCompletion", ThisObject), "Should I close the form?", DialogModeQuestion.YesNo); endIf; End of Procedure &On Client Procedure Before Closing Completion (Question Result, Record Parameters) Export If Question Result = Dialogue Return Code. Yes Then Execute Closing = True; Close(); endIf; End of Procedure

This example is similar to our topic and is often referenced in the topic “Show Question in the Before Post Form Handler”:

There may also be a need to ask a question in the BeforeRecord form event handler. As in the previous example. However, the issue here is not so easily resolved. The difference is this.

In the previous example, once we were in the BeforeClose handler, we clearly knew the action that should be performed. This is closing the form. Therefore, when processing the alert, we boldly wrote Close().

But in the BeforeRecord handler we do not have such unambiguous information. We can end up in this handler for two reasons: if the user clicked Record, or if he clicked Record and Close. That is, the further scenario of actions is unknown to us. We cannot define it using standard methods while inside this handler.

Therefore, here we can offer three options, but, unfortunately, they all have disadvantages:

* Change the logic of the application solution so that there is no dialogue with the user in this handler. This is not always possible;

* When processing an alert using your own blocking form, ask the user a detailed question that provides an accurate description of further actions: Refuse?, Record only?, Record and close? This may not look very nice, because the user has already clicked “Save and close”, and he is asked about it again;

* Do not use standard commands of the Write, "Save and Close" form. Instead, create your own commands in which to execute the necessary algorithms. Creating your own teams will require additional labor costs.

The task is complex, so the developers, when asking a question before Recording, first of all recommend abandoning this idea...

Then they ask you to ask a question with many options: “Refuse, Only record, Record and close.” In addition to the described disadvantage (the user already selects an option in advance, and is then asked again), there is also one more thing: the program could also be accessed from Before Recording from “Cancellation”. Those. Do I need to add another button? I think this option is ugly.

There remains only the third option using non-standard form commands. We will implement it. And the only non-standard command we will have is “Post and close”. As in the example on the topic “Question in the BeforeClose form handler”, we will have to give Refusal = True on the first call, and only on the second call do the actual recording. And somewhere we will need to remember that this is the second entry into the “BeforeRecording” procedure. 1C suggested doing this through a common client variable; in the example under consideration, this can be done through Recording Parameters.

Example of using ShowQuestion in the BeforeRecord form handler

1. First, we need to remove the standard “Swipe and close” command from the form and create our own command and button.

1.A. If you already have a non-standard “Swipe and close” button, you’re in luck, you can safely proceed to step 2.

1.B. The standard command is removed via Form Properties - Command Composition - Remove the unnecessary command. I will not describe how to add a command and a button to the form, I will only remind you that the “Submit and Close” button must be made the default button.

1.V. Now the option is more difficult to implement, but easier to maintain with a standard configuration. In almost every Accounting update, programmers manage to change 10-50% of document forms, so in a typical configuration for maintenance it is easier to remove the standard button by code and add your own command and button.

To begin with, in the “On Opening” form handler, you need to remove the standard “Proceed and Close” button.

Elements.FormSwipeIClose.Visibility = False;

Note: for a user with large restrictions on a document in platform 8.3.7, the “Post and Close” button does not appear at all. Therefore, for platform 8.3.7 it is more correct to write code:

If Elements.Find("FormProductIClose")<>Undefined Then Elements.FormSwipeIClose.Visibility = False; endIf;

NewCommand1 = ThisForm.Commands.Add("SwipeANDClose2"); NewCommand1.Action = "SwipeIClose"; NewElement = Elements.Add("FormAddAndClose2" , Type("FormButton"), Elements.FormCommandBar); NewElement.Title = "Swipe and close"; NewElement.CommandName = NewCommand1.Name; NewElement.DefaultButton = True; Elements.Move(NewElement, NewElement.Parent, Elements.CommandBarButtonGroup);

Accordingly, this code contains typical names for the General Document Form of the document “Receipt (acts, invoices)” (for example, Elements.GroupButtons of the CommandBar), which in each specific case will need to be changed to your own.

&OnClient Procedure RunIClose(Command) Record Parameters = New Structure(); Recording Parameters.Insert("Recording Mode", PredefinedValue("DocumentRecordingMode.Post")); Record Parameters.Insert("Close", True); If Write(Record Parameters) Then Close(); endIf; End of Procedure

As I wrote above, we will exchange information between our procedures through Record Parameters. In Before Recording, we don’t know whether we clicked “Record”, “Post” or “Post and Close”, for this we pass the Close parameter in the parameters. If there is this parameter in the entry parameters, then you need to close the form after a successful entry.

3. Let’s say we don’t always need to ask the question, but only when the document has been processed. Now we add (if this procedure did not exist, create) a new code to the “BeforeRecording” procedure:

If Not RecordParameters.Property("QuestionAsked") AND Object.Passed Then Failure = True; Alert = New AlertDescription("ShowQuestionComplete", ThisForm, PostOptions); Question Text = "This document has already been posted. Do you really want to re-post or cancel posting of the document?"; ShowQuestion(Alert, QuestionText, DialogModeQuestion.YesNo, 20,DialogReturnCode.No,DialogReturnCode.No); endIf;

We will fill in the “Question Asked” property in the notification to find out when we entered the “BeforeRecording” procedure for the second time (in example 1C in the BeforeClosing procedure this was done through the “Closing in Progress" variable). In other words: in the “Record Options” structure there is a “Question Asked” property, which means that the question has already been asked, and the user has already answered in the affirmative, but if there is no property, then this is our first time in the “Before Record” procedure.

After the ShowQuestion method, you can also write “Return” if you have some other code in the “BeforeWrite” procedure that is executed after the question.

4. Create a “Show QuestionComplete” procedure, which the program will enter when the user answers the question (or a timeout occurs).

&On the Client Procedure ShowQuestionCompletion(Result, Record Parameters) Export If Result = DialogReturnCode.Yes Then Record Parameters.Insert("QuestionAsked", True); If Write(RecordParameters) ANDRecordParameters.Property("Close") Then Close(); endIf; endIf; End of Procedure

In this procedure we use the “Close” property passed earlier. If there is no property, then there is no need to close it.

5. Now we need to process the user pressing the “cross”. To do this, we need a “BeforeClose” form handler. If it does not exist, then it can be created on the form manually or programmatically in the “When CreatedOnServer” handler:

ThisForm.SetAction("BeforeClose","BeforeClose");

&OnClient Procedure BeforeClose(Failure, StandardProcessing) If Modified Then Failure = True; QuestionText = НStr("ru = "The data has been changed. Do you want to save the changes?""); Alert = New AlertDescription("QuestionBeforeClosingCompletion", ThisObject); ShowQuestion(Alert, QuestionText, DialogModeQuestion.YesNoCancel); endIf; End of Procedure &On the Client Procedure QuestionBeforeClosingCompletion(Result, AdditionalParameters) Export If Result = DialogReturnCode.Yes ThenRecordParameters = New Structure(); Record Parameters.Insert("Close", True); If Write(Record Parameters) Then Close(); endIf; ElseIf Result = DialogReturnCode.No Then Modification = False; Close(); endIf; End of Procedure

It turns out that when the user clicks the cross, he will first answer the question “Save changes?” and then another question will be asked, which you have written “Before Recording”. If you are not satisfied with this, you can pass the “QuestionAsked” parameter to “QuestionBeforeCloseCompletion” and then there will be no second question.

Question vs ShowQuestion

How would we solve the problem if we could use modal calls? And very simply, we would write the following code in the “BeforeWrite” procedure:

If Object.Posted Then Question Text = "This document has already been posted. Do you really want to re-post or cancel posting of the document?"; Answer = Question(QuestionText,DialogModeQuestion.YesNo,20,DialogReturnCode.No,DialogueReturnCode.No); If Not Answer = Dialogue Return Code. Yes Then Refusal = True; Return; endIf; endIf;

That's all! No “troubles” like “What did the user click: Swipe or SwipeAndClose?” And you will also need to practice pressing the cross in “Before Closing”.

Initially, I implemented similar code in my Enterprise Accounting 3.0. The task was as follows: under a certain set of conditions (this is not just one condition Object.Performed, as indicated in the example in this publication) from the Document Form General document Receipt of Goods and Services, ask for additional confirmation of his actions. Listed below are the nuances that I did not have to bypass, because... were not up to the task.

The program does not enter the “Before Entry” form processor if: 1) the user clicked on the “Mark for deletion / unmark” button; 2) if the user pressed the “DT/CT” button on an unchecked document. And that’s not all: if you created everything on the document form as I wrote, and the user re-enters the document from the list form, then the program will not ask him any questions. You need to replace all the buttons you are interested in on the list form with your own and track user actions. A document may also have more than one document form, but several (for example, the document Receipt of Goods and Services in BP 3.0, where there are 3 forms: general, goods and services). In each document form you need to write a lot of code...

Due to a bunch of nuances, the first advice from 1C remains relevant (which at first, without delving into the task in detail, can make you smile): “Change the logic of the application solution so that there is no dialogue with the user in this handler.”

Let's define what dialogue is? Calling a command To report is a dialogue? And the team call Enter Number! A challenge OpenValue?

So, dialogue is first of all an element of graphical interface. window. And therefore the challenge To report is not a dialog, since it does not have its own separate window.

Dialogue is not just a window. This is a window that opens to the user to display information and (or) receive a response.

Examples of dialogues:

1 C: Enterprise X

Department of Applied Informatics

iignichchіїїїїїїїїзініїїїїїїїїїїїїїїїї

In order to show a dialog, you need to call the command corresponding to this dialog and pass the necessary parameters to it. This command is a regular procedure or function, only written not by us, but by 1C programmers. We cannot change these commands, we can only call them. Let's look at some of them.

Warning

An excellent example of a dialog is to display a warning to the user:

Warning("Caution!");

What do we see? Calling a command Warning, to which the string “Caution” is passed as a parameter.

When the computer reaches the line where this command is called, a warning dialog will be displayed to the user. And until the user closes this dialog, the computer will wait on the same line. Only after closing the dialog will program execution continue and execution of the line following the call of the dialog will begin.

For example, let's say we have this code:

Warning(" 1");

Warning("2");

Warning("3");

How will it be implemented?

First, the computer will reach line No. 1 and execute the command Warning with parameter "1". At this moment, the user will see a dialog box with the text “1”, and the computer will freeze on this line and wait for the user to close the dialog.

After closing the dialog, the computer will proceed to line No. 2 and execute the command Warning already with another parameter "2". The user will again see the dialog box, but with the text “2”, and the computer will freeze on the second line and wait for the user to close the dialog.

The computer will then move to the third line. Well, and so on.

The team Warning the parameter responsible for the text that is displayed is not the only one. There are two additional options:

Warning(,, )

Time-out- means the number of seconds after which the dialog will close itself if the user does not do so.

Heading- replaces the standard title "1 C: Enterprise" with the user's line.

For example, this code:

Warning("Caution.", 5, "Attention!");

will show a dialog with the text "Caution." and the heading "Attention!", and will also close in 5 seconds if the user does not do this earlier:

Attention!

Carefully.

But what if we want to set only the text and title of the window, and not set the timeout?

First, we can pass zero as the timeout:

Warning("Caution.", Oh, "Attention!");

And secondly, we can simply leave an empty space instead of the parameter, and the system itself will understand that we need to leave its default value:

Warning("Caution.", "Attention!");

In order to learn about all the possible parameters of the built-in 1C commands, use the syntax assistant as described in one of the previous units.

Entering a number

Some dialogs not only display some information from us to the user, but, on the contrary, return some result of interaction with the user. An example of such a dialog is entering a number.

For example, let's write:

EnterNumber(Number);

Enter the number

Why do we pass a parameter to the command? Number? Firstly, in order to display the initial value of the input in the dialog. And, secondly, to return the value entered by the user to this variable.

But what if the user abandoned the input and clicked the Cancel button? How to find out about this? It turns out that the function EnterNumber not only shows the number input dialog, but also returns to us True if the user clicked the "OK" button, and Lie, if he canceled the input by clicking the "Cancel" button.

Thus, the following code would be more correct:

Result = EnterNumber(Number);

If Result = True Then OpenValue("You entered " + String(Number));

OpenValue("You canceled your entry");

endIf;

To a variable Result(the name could be anything) returns True or False depending on which button the user pressed ("OK" or "Cancel").

To a variable Number returns the number entered by the user.

Question

The final dialog we'll look at is the Ask the User dialog.

We know the name of the command that causes this dialog - Question.

Now let's look in the syntax assistant to see what parameters this command accepts:

Question(, >)

Question Text- this is the question itself in text form that the user will see.

Buttons- this is one of the predefined values, which can also be viewed in the syntax assistant. For example, if you pass to this parameter:

  • Dialogue ModeQuestion.YesNo - the dialogue will have only two buttons Yes and No.
  • Dialogue ModeQuestion.YesNoCancel - three buttons Yes, No and Cancel.
  • Dialogue ModeQuestion.OkCancel - two buttons Ok and Cancel.
  • And other button options.

Time-out- This parameter is already familiar to us.

ButtonDefault- this is the button that will have focus when the window is shown. Its meanings could be:

  • Dialogue Return Code.No
  • Dialogue Return Code.Yes
  • Dialogue Return Code.Cancel
  • And other buttons.

Heading- this parameter is already familiar to us.

Timeout Button- if you set the value of this button and the parameter Time-out, then it will display the number of seconds remaining until the dialog closes. It can have the same values ​​as the parameter ButtonDefault.

As you can see, there are many parameters. But you don't have to use them all. As follows from the syntax assistant, only the first two are required:

Question (“Do you understand the material?”,

Dialog mode Question.Yes No);

We asked a question. It would be nice to now get an answer whether the material is clear or not. From the same syntax helper we learn that the button that was clicked is returned as the result of the command call Question.

Result = Question("Do you understand the material?", DialogModeQuestion.YesNo);

If Result = DialogReturnCode.Yes Then OpenValue("What a great guy you are!");

OpenValue("Do the tasks again!");

endIf;

Modality

All of the dialog examples we've looked at are modal because the computer, when showing the dialog, freezes on the same line and doesn't move on until the dialog closes.

Another way to say it is that when we show a modal dialog, the user can only interact with that dialog. Operation with the rest of the system is blocked until the dialog is closed.

Non-modal versions of dialogues do not have this disadvantage, but it is too early for us to move on to them.

To practice and consolidate the material of this unit, it is recommended to complete the following task.

Write a program that asks the user "Press Yes to display numbers from 1 to 10, No to display numbers from 10 to 100, do not press the Cancel button under any circumstances." The dialog should have three buttons Yes, No and Cancel.

If the user clicked Yes, we display numbers from 1 to 10, No, from 10 to 100, Cancel, we display a warning dialog with the text “We warned you not to press cancel!”

Solution

Result = Question(

"Click Yes to display numbers from 1 to 10" +

", No - to display the numbers 10 to 100, in no way" +

"in this case, do not press the Cancel button", Dialogue ModeQuestion. YesNoCancel);

If Result = DialogReturnCode.Yes Then For Step = 1 To 10 Cycle Report(Step);

EndCycle;

OtherwiseIf Result = DialogReturnCode.No Then For Step = 10 By 100 Cycle Report(Step);

EndCycle;

OtherwiseIf Result = DialogReturnCode.Cancel Then OpenValue("We warned you not to press cancel!");

Ask a question about accounting and within seven working days you will receive a response from an auditor or methodologist from 1C.
You can ask a question at: [email protected] or using a web form.

Terms of Use

Questions are accepted on the following topics:

  • the procedure for recognizing the organization's income and expenses;
  • taxation and recording of specific business transactions;
  • filling out accounting (including primary) documents;
  • determination of the taxable base for taxes and contributions;
  • procedure for paying taxes and contributions;
  • filling out and submitting accounting and tax reporting, as well as reporting on contributions;
  • the procedure for hiring, rewarding, applying penalties and dismissing employees;
  • the procedure for assigning various payments to staff (vacation pay, benefits, compensation);
  • filling out various personnel documents.

Exceptions include questions

  • on organization and optimization of business;
  • on optimization of taxation and choice of organizational and legal form and taxation regime;
  • related to risk assessment;
  • relating to legal relations that are regulated by foreign, regional and local legislation;
  • on the preparation and evaluation of legally significant documents (agreements, acts, claims, lawsuits, orders, instructions, etc.);
  • on the assessment of business transactions carried out in a certain way;
  • relating to currency regulation;
  • formulated incorrectly (the content of the question does not allow it to be answered correctly);
  • issues related to taxation of individuals.

Only one question is accepted from one user at a time. The user can send the next question after receiving the answer to the previous question.

Price

    The “Auditor Answers” ​​service is included in the 1C:ITS PROF level information technology support packages.

Additionally

How to ask a question correctly

  • Indicate the name and legal form of the organization.
  • Indicate the registration number of the program for which the 1C:ITS Agreement is issued.
  • Describe the business situation that prompted the question:
    • formulate the conditions under which it arose;
    • indicate the actions that were performed;
    • indicate the features that affect the answer (tax regime, period of the transaction, etc.).
  • Formulate your thoughts clearly and competently.
  • Each question must be sent in a separate letter. If you receive a letter that contains several unrelated questions, only the first question will be answered.

Form and terms of use of the answer

  • Answers are provided only to questions regarding the economic activities of the legal entity or individual entrepreneur asking them.
  • The answer to each question is given in writing and does not imply a detailed audit opinion.
  • Each answer to a question is the result of the intellectual activity of 1C employees. Reply rights are protected by civil law. The exclusive right to each answer belongs to 1C LLC. An organization or individual entrepreneur has the right to use the response received to resolve situations that arise in the course of their business activities. The user who asked the question does not have the right to provide the answer received from 1C (or any part of it) to third parties or use it in their activities in any other way, except for resolving their controversial issues. The 1C company reserves the right to stop consulting an organization (or individual entrepreneur) that has violated these conditions.
  • The answers reflect the opinion of 1C specialists and are advisory in nature. The user makes the decision to use them in practice independently.
  • 1C Company reserves the right to use questions and answers in consulting materials without the consent of the person asking the question.
  • Information on questions asked (quantity and content) can be transferred to a partner organization of the 1C company, with which the person asking the question has a support agreement.

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

Applicability

The article discusses the asynchronous model for constructing business logic, the added platform “1C:Enterprise” edition 8.3. The information presented is relevant for current platform releases.

Refusal to use modal windows in the 1C:Enterprise 8.3 platform

When developing a configuration on the 1C:Enterprise 8 platform, the need periodically arises to pause the program until the user makes a decision or performs some action.

For example, when clicking on the fill tabular section button, the user should be asked whether the tabular section needs to be cleared so that previously entered data is not lost.

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

&OnClient
Procedure Fill in Products(Team )
Answer = Question (“The table part will be cleared. Continue?”, Dialogue ModeQuestion.YesNo);
If Answer = Dialogue Return Code.Yes Then
//filling algorithm
EndIf ;
End of Procedure

As a result of this code fragment, the execution of the program code will be suspended, a question will be displayed on the screen, the application interface except for the dialogue with the question will become unavailable, the system waits for the user to make a decision, and code execution will continue only after the question is answered.

Opening modal windows by calling the OpenModal() method also causes pauses in code execution and blocking of the interface.

When working with the configuration in web client mode through a browser, in this case a new window will open - a pop-up window that will block not only the current tab, but also the entire browser interface, including other open windows and tabs.

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

In this case, to work with 1C:Enterprise 8 configurations through a browser, you must disable pop-up blocking.

Problems also arise when working on mobile devices. For example, modal windows are not supported on iPad.

To solve these problems, you should use blocking windows instead of modal ones. For the user, visually everything looks the same: the window blocks the web client interface.

However, the blocking window is “drawn” on top of the main window, and only the current browser tab in which the configuration is open is blocked, allowing you to switch to other tabs, since modal browser windows are not used.

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

The root element of the configuration has a property “Modality mode”, which determines whether modal windows can be opened in the configuration.

If the “Use” option is selected, then modal windows can be opened. If the “Do not use” option is selected, then modal windows are not allowed. When you try to call a method that opens a modal window, the system displays an error message:

With this value of the “Modality usage mode” property, only blocking windows are allowed.

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

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

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

Therefore, developers will have to rewrite the program code that uses modal windows to take this feature into account.

The code needs to be divided into two parts:

  • opening a blocking window;
  • processing user selection.

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

&OnClient
Procedure Fill in Products(Team )
Alert = New DescriptionAlerts(, ThisObject );

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

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

The user will be able to make a choice only after the entire procedure is completed. In this case, the export procedure FillItemsQuestionComplete() will be called. We passed its name to the constructor of the DescriptionAlerts object.

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

In the example considered, the called procedure is located in a managed form module, so we passed in the ThisObject parameter.

Let's consider calling a procedure located in a general module. To do this, add a new common module Notification Processing, set the “Client (managed application)” flag for it, and do not set the “Global” flag. Let's place the procedure Fill in Products Question Completion () in this module.

Then the fill command handler will look like this:

&OnClient
Procedure Fill in Products(Team )
Alert = New DescriptionAlerts(“Fill in Products Question Completion”,
ProcessingAlerts);
Question Text = “The tabular part will be cleared. Continue?" ;
ShowQuestion (Alert , Question Text , Dialogue ModeQuestion.YesNo);
End of Procedure

After calling any method that opens a blocking window, the procedure must exit, and the code that runs next should be placed in a procedure that will be called after the window is closed.

To transfer context (auxiliary data, certain parameters, variable values) from the procedure that opens the modal window to the procedure called when it is closed, a third optional parameter of the object constructor is provided: DescriptionAlerts – Additional Parameters.

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

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

&OnClient
Procedure Fill in Products(Team )
Parameter1 = 0 ;
Parameter2 = 0 ;
List of Parameters= New Structure (“Parameter1, Parameter2″, Parameter1, Parameter2);
Alert = New DescriptionAlerts(“Fill in Products Question Completion”, ThisObject ,
List of Parameters);
ShowQuestion (Alert, “The table part will be cleared. Continue?”,
Dialogue ModeQuestion.YesNo);
End of Procedure
&OnClient
Procedure Fill inProductsQuestionCompletion(Result , Extra options) Export
If Result = Dialogue Return Code.Yes Then
//analyze Additional Parameters.Parameter1
//analyze Additional Parameters.Parameter2
EndIf ;
End of Procedure

If you need to pass only one value, then you can not use the structure, but assign this value to the Additional Parameters parameter of the constructor of the DescriptionAlerts object.

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

Task 1: Open another form

From the document form, by clicking on the “Open parameters” button, you need to open a form on which there are two checkboxes Parameter1 and Parameter2, which the user must set. After closing the form, display the parameter values ​​in the message line.

We create a general form “ParametersForm”, on which we place the details Parameter1 and Parameter2, as well as the CloseForm command:

The command handler looks like this:

The command handler looks like this: &OnClient
Procedure CloseForm (Command)
List of Parameters= New Structure ( “Parameter1, Parameter2”, Parameter1 , Parameter2 );
Close ( List of Parameters); End of Procedure

For the form, set the WindowOpenMode property to “Block entire interface”:

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

&OnClient
Procedure OpenOptions(Team )
Alert = New DescriptionAlerts(“Open Options Finish”, ThisObject );
OpenForm ( “GeneralForm.FormParameters”, , , , , , Notification);
End of Procedure
&OnClient
Procedure OpenOptionsComplete(Result , Extra options) Export
If TypeValue (Result) = Type (“Structure”) Then
For each KeyValue From Result Loop
Message = New Message to User;
Message.Text = “Key: “” ” + KeyValue.Key + “””, value = ”
+ KeyValue.Value;
Message.Report();
EndCycle ;
EndIf ;
End of Procedure

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

To enlarge, click on the image.

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

&OnClient
Procedure OpenOptions(Team )
Alert = New DescriptionAlerts(“Open Options Finish”, ThisObject );
OpenForm ( “GeneralForm.FormParameters”, , , , , , Alert
FormWindowOpenMode.LockEntireInterface
);
End of Procedure

Task 2. Question when closing the form

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

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

&OnClient
Perem Need to Close the Form;
&OnClient
Procedure Before Closing (Failure, StandardProcessing)
If not Need to Close the Form= True Then
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 the standard color selection dialog, the user specifies the required color. Set this color for the background of the clicked button.

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

&OnClient
Procedure Color Selection (Command)
Color Selection Dialog= New Color Selection Dialog;
Alert = New DescriptionAlerts(“Color SelectionComplete”, ThisObject );
Color Selection Dialog. Show(Alert);
End of Procedure
&OnClient
Procedure ChoiceColorsCompletion(Result , Extra options) Export
If NOT Result = Undefined Then
Elements.Color Selection.Background Color= Result ;
EndIf ;
End of Procedure

For Color Selection Dialog objects (as well as Standard Period Editing Dialog, Format Line Constructor, Regular Task Schedule Dialog, Font Selection Dialog), the Show() method opens a blocking window.

After closing the window, a procedure will be called, the first parameter of which will be passed the selected value (color, font, etc.) or the Undefined value if the user has refused the choice.

It should be noted that the FileSelectionDialog object does not have a Show() method, unlike color or font selection dialogs, since the implementation of these dialogs is significantly different.

To use the file selection dialog on the web client, you must first enable the file extension.

Dialogs implemented through the file extension do not create the same operational problems as modal browser windows, so opening blocking windows for the FileSelectionDialog object was not implemented.

In conclusion, we note that starting with release 8.3.10, support for modal windows has been discontinued in the web client. In this case, if a modal method is called in the configuration, an exception is generated. Also, support for interface mode has been discontinued in the web client In separate windows. In addition, in both the thin and web clients it is no longer possible to open a form in a separate window (when working in the Bookmarks interface mode). Such drastic steps made it possible to abandon the interface mode, which is no longer supported by all modern browsers.

What practical conclusion can be drawn from this information? And the conclusion is quite simple - if for some reason there are still modal calls in your configuration, then in these places in the web client a window with an error message will be displayed. I would like to warn against trying to “Google” some quick solution to this problem, because... Most of the advice comes down to this recipe: in the configurator at the configuration level, set the “Modality usage mode” property to “Use”. Naturally, at the moment, this will not work only because modern browsers themselves no longer support modal calls.

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

  1. 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
  2. Recommend your clients to use older browsers that still supported modal calls (Mozilla Firefox versions 37 and below, Chrome versions below 37, etc.).

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

We have dealt with web browsers in the light of modality, now it’s time to clarify the situation with other clients.

Starting with version 8.3.5, the Modality Usage Mode property in thin and thick clients is respected only if the /EnableCheckModal command line option is specified. This parameter is automatically inserted into the command line only when the application is launched from the configurator. If this parameter is not specified, then no exceptions are generated and corresponding warnings are not shown. Those. in practice, when using a thick and thin client, no fundamental change in operation is observed when using the modal mode - modal calls will work the same as they worked before, without producing any warnings, as in the web client.

To dot the i's, note that starting with version 8.3.9, the thick client ignores the configuration property “Mode of using synchronous calls to platform extensions and external components”, while the corresponding synchronous methods work without generating exceptions and displaying warnings. The specified ignored property was added in version 8.3.5 to support asynchronous work with external components, cryptography and extensions for working with files in the Google Chrome web browser. It is clear that this has nothing to do with the thick client, and therefore “quietly” ignoring this property simply eliminated unnecessary checks for the use of synchronous methods when using the configuration.

By the way! Due to the fact that the platform is confidently moving towards the web, with version 8.3.8 the developers have introduced certain restrictions on the program code that is associated with the logic for closing a form or application, executed in thick and thin clients. Be sure to read our article covering this nuance in detail. In addition, in the course “Professional development of interfaces and forms in 1C: Enterprise 8.3”, there is a chapter dedicated to the abandonment of modality, and you can glean a lot of useful and relevant information on this topic.

Colleagues, there are two things that you can read endlessly: the VKontakte feed and the list of changes in the next release of the platform, so let’s sum up the final results;)

In the process of considering examples that allow you to move from elements of a synchronous model to an asynchronous one, you probably already noticed that in the general case there is more program code. The more code there is, the more the complexity of its further maintenance and debugging increases.

In addition, the amount of code will increase even more if we use more dialogs during the development process. Therefore, in the process of developing application solutions focused on working in a web client, you need to remember the work paradigm that is currently used in modern web applications. Therefore, if your configuration has a lot of interactive dialogs with the user and warnings, then it makes sense to reconsider this functionality in favor of some other approaches to organizing user interaction.

Instead of a conclusion

Our cycle “First steps in 1C development” has come to an end. If you read it in its entirety, then most likely you have already noticed how the platform has been developing by leaps and bounds lately. The material in this series was written relatively recently, but we were forced to seriously update it, because... Even in such a short period of time, a lot of new important functionality and changes have appeared. Such major changes can be somewhat perplexing for a 1C programmer if he has not grown and developed professionally with the platform all this time.

On specialized Internet resources you can often read requests from novice programmers and their more mature colleagues to recommend materials that would help them understand the extensive and sometimes seemingly endless capabilities of the 1C platform. We, traditionally, recommend that you pay attention to our programming courses