But some aspects of working with the “Message to User” object remained not covered in it. For example, what to write in the "Field" field if the name
props differs from the field name on the form. What to write in the "Path to Data" field. And finally, the most delicious thing is how to work with the tabular part.
All research is collected in a test database. It contains a couple of reference books and a document. The document form has several buttons, when clicked, various types of messages are displayed. Well, now about each moment in order, let's go!!!
Everything I write below has been tested on 1C:Enterprise 8.3 (8.3.7.1860). Not the latest to date, but I’m writing it as it is.
1. Just a message.
Let's start with something simple: just display a message in the form, without reference to fields, data, etc.
I talked about this earlier, but for the integrity of the article I will write it again. Especially with some additions.
Message1 = new MessageToUser;
Message1.Text = "1. just a message without any bindings";
Message1.Message();
This code can be executed on both the client and the server. This is almost a complete analogue of the line:
Report("1. just a message without any bindings");
Why is it more correct to communicate not with a procedure, but with an object. The fact is that messages issued in background job(for example, when performing a routine procedure on a schedule) are not displayed anywhere. But what is communicated by the object can be
receive on the server in a client session using the "GetMessagesToUser(...)" method while the background job is alive.
Here I lied to you a little, I never checked it. It is quite possible that messages issued by the “Report(...)” procedure can also be obtained from a background job, but maybe not. The documentation doesn't say about this, which means we
we won't do it.
So, conclusion: now always make messages an object, it's kind of good form new platform, and forget the procedure. If you don’t like writing a message in three lines, then write your procedure in a general module and be happy. It will even
very good tone, because You will receive a number of advantages:
1. Expanded functionality of the new object (more details below)
2. The ability to display messages in your own way. For example, in a text field or file, and not in a message window.
3. Possibility of logging. For example, you can save all messages in a database or a file, or duplicate them in the log, to do this, just tweak your procedure common module. And then the debate is that the program is nothing to the user
did not inform will stop forever.
2. A message associated with an object attribute.
As I wrote in the previous article, to bind you need to fill in the “Field” and “PathKData” fields. But I did not cover the topic in detail in the article.
So example 2 in the document there is a header attribute “Client”, you need to position yourself on it and report something in the client procedure. Here's the code that does this:
Message2 = new MessageToUser;
Message2.Text = "2. Message associated with the Client header attribute";
Message2.Field = "Client";
Message2.DataPath = "object";
Message2.Message();
And here are the nuances:
1. A field is not a field, because in my example the control is called "FieldClient" and the object prop is "Client". The line Message2.Field = "FieldClient" does not work.
2. The Path to Data is not “Object.Client”, but simply “Object”, because We need to show the message not in the form of the counterparty, but in the form of the current document. "Object.Client" - does not work.
3. This is an example of working on a client. In server procedures, it’s a little different. This is IMPORTANT, do not confuse the binding of messages on the server and on the client.
I will give one more example so that you can feel the difference between a client and a server. The fact is that we have at our disposal the object method “SetData(...)”. The syntax helper says "The object with which there should be
message is associated." This is important. For example, let's write the following code:
Message3 = new MessageToUser;
Message3.SetData(Object);
Message3.Text = "3. Message linked to the header attribute Number, but it will not be linked because the Object is not an object";
Message3.Field = "Number";
Message3.Message();
This code won't work because... on the client, the “Object” form attribute is not an object at all, but some kind of nasty thing, this is what the debugger tells us about the object variable:
More precisely, the user will of course see the message, but tapping it twice will not lead to anything.
Now let's try the same thing, but on the server. Let's create a server procedure "Report4OnServer()" and call it from the client
&OnServer
Procedure Report4OnServer()
Message4 = new MessageToUser;
Message4.SetData(FormAttributesValue("Object"));
Message4.Text = "4. Message associated with the Organization header attribute";
Message4.Field = "Organization";
Message4.Message();
End of Procedure
Everything will be fine here, the only remark on the code is that the “object” variable must be converted from “FormDataStructure” into a real object by calling the “FormAttributesValue(...)” procedure.
Conclusion: the "SetData(...)" method can only be used on the server, because Only on the server is it possible to receive an object.
3. Messages linked to the attribute of the tabular part of the object
I omitted this topic in the previous article. Knowing the nuances described above, there should be no problems here. Here is the working client code:
Message5 = new MessageToUser;
Message5.Text = "5. Line 1 field quantity";
Message5.Field = "Products.Quantity";
Message5.DataPath = "object";
Message5.Message();
Although the nuances are almost the same, repetition is a mother lesson:
1. The field is not the name of the control; my control is named “ProductsQuantity”, not just “Quantity”. "Products" is the name of the tabular part, not the control element associated with the tabular part.
2. The path to the data is an object, just an object.
3. Line number in square brackets - numbering from scratch and this is the line number, not the line identifier in the form data collection. When shifting lines or deleting them, the identifier assigned when opening the form is saved, and the line numbers are recalculated.
That's it for this time. I’ll immediately mention undisclosed topics that I’ll write about later:
1. How to bind messages not to the current object, but to any object, so that when you double-click, another form opens
2. How to bind messages to a form where there are no objects
3. How to receive messages about the execution status of a long-background job
4. What is a “Data Key” and when should you use it?
Below is a database with an example, in it go to the document and press three buttons in turn. Code in the document form module.
2. A message associated with an object attribute.
As I wrote in the previous article, to bind you need to fill in the “Field” and “PathKData” fields. But I did not cover the topic in detail in the article.
So example 2 in the document there is a header attribute “Client”, you need to position yourself on it and report something in the client procedure. Here's the code that does this:
Message2 = new MessageToUser;Message2.Text = "2. Message associated with the Client header attribute";
Message2.Field = "Client";
Message2.DataPath = "object";
Message2.Message();
And here are the nuances:
1. A field is not a field, because in my example the control is called "FieldClient" and the object prop is "Client". The line Message2.Field = "FieldClient" does not work.
2. The Path to Data is not “Object.Client”, but simply “Object”, because We need to show the message not in the form of the counterparty, but in the form of the current document. "Object.Client" - does not work.
3. This is an example of working on a client. In server procedures, it’s a little different. This is IMPORTANT, do not confuse the binding of messages on the server and on the client.
I will give one more example so that you can feel the difference between a client and a server. The fact is that we have at our disposal the object method “SetData(...)”. The syntax helper says "The object with which there should be
message is associated." This is important. For example, let's write the following code:
Message3 = new MessageToUser;Message3.SetData(Object);
Message3.Text = "3. Message linked to the header attribute Number, but it will not be linked because the Object is not an object";
Message3.Field = "Number";
Message3.Message();
This code won't work because... on the client, the “Object” form attribute is not an object at all, but some kind of nasty thing, this is what the debugger tells us about the object variable:
More precisely, the user will of course see the message, but tapping it twice will not lead to anything.
Now let's try the same thing, but on the server. Let's create a server procedure "Report4OnServer()" and call it from the client
&OnServerProcedure Report4OnServer()
Message4 = new MessageToUser;
Message4.SetData(FormAttributesValue("Object"));
Message4.Text = "4. Message associated with the Organization header attribute";
Message4.Field = "Organization";
Message4.Message();
End of Procedure
Everything will be fine here, the only remark on the code is that the “object” variable must be converted from “FormDataStructure” into a real object by calling the “FormAttributesValue(...)” procedure.
Conclusion: the "SetData(...)" method can only be used on the server, because Only on the server is it possible to receive an object.
3. Messages linked to the attribute of the tabular part of the object
I omitted this topic in the previous article. Knowing the nuances described above, there should be no problems here. Here is the working client code:
Message5 = new MessageToUser;Message5.Text = "5. Line 1 field quantity";
Message5.Field = "Products.Quantity";
Message5.DataPath = "object";
Message5.Message();
Although the nuances are almost the same, repetition is a mother lesson:
1. The field is not the name of the control; my control is named “ProductsQuantity”, not just “Quantity”. "Products" is the name of the tabular part, not the control element associated with the tabular part.
2. The path to the data is an object, just an object.
3. Line number in square brackets - numbering from scratch and this is the line number, not the line identifier in the form data collection. When shifting lines or deleting them, the identifier assigned when opening the form is saved, and the line numbers are recalculated.
That's it for this time. I’ll immediately mention undisclosed topics that I’ll write about later:
1. How to bind messages not to the current object, but to any object, so that when you double-click, another form opens
2. How to bind messages to a form where there are no objects
3. How to receive messages about the execution status of a long-background job
4. What is a “Data Key” and when should you use it?
Below is a database with an example, in it go to the document and press three buttons in turn. Code in the document form module.
1C Message to User displays a message to the user (after processing is completed) or saves it in a queue if the message cannot be displayed “right now”, for example:
Message = New MessageToUser();
Message.Text = "Hello, world!";
Message.Message();
In many cases, messages are generated in bulk during certain processing. For example, when checking a large table, many error messages may appear in different rows of the table. Or when processing a transaction. In this case, processing can be carried out on the server or in regulatory task and it is difficult to display these messages.
1C Message to User writes messages to “some” queue, and, after processing is completed, displays them to the user, if possible. Otherwise, the entire list of messages can be obtained using the GetMessagesToUser() method.
To display a message to the user using 1C Message to User in a specific, already open form, you additionally need to set the form identifier:
Message.DestinationIdentifier = Form.UniqueIdentifier;
In order for the 1C Message to User message to be displayed in a pop-up window next to a specific field of the form in which the code is executed in the module, you need to specify the “path” to it:
Message.Field = "Name"; //where Name is a form attribute
Message.Field = "Object.Name"; //where Name is the attribute of the object (i.e. the directory whose form is being edited)
Message.Field = "Products.Price"; //where Products is the tabular part of the form, Price is the column of this tabular part
To do the same, but in a module of another object (general module), you need to additionally specify the object (DirectoryObject, DocumentObject, etc.):
Message.Field = "Name"; //where Name is the DirectoryObject attribute
Message.SetData(DirectoryObject);
//At double click In response to the message, the object form will be opened with a pop-up message for the required field
Another way to associate a 1C Message to User message with object data:
//for a reference book, document..
Message.DataKey = DirectoryLink;
Message.DataPath = "Object";
//for register entries
Message.DataKey = RegisterRecordManager.InitialRecordKey; //usually the main form attribute associated with the register
Message.DataPath = "Record";
In standard configurations on controlled forms for a thin client, for example, “Trade Management, edition 11” and “Accounting, edition 3”, in the general General PurposeClientServer module there is a function NotifyUser(), which “universals” the work with this object. The syntax of functions in different configurations is different.
Since 1C Message to User generates a list of messages, in order to reset it (for example, before performing complex processing), you can call the function:
GetMessagesUser(True);
In programs on the 1C:Enterprise platform, a message can be shown to the user in different ways.
1. Method ShowWarning.
ShowWarning(< ОписаниеОповещенияОЗавершении> , < ТекстПредупреждения> , < Таймаут> , < Заголовок> )
When using this design, a warning window appears in the center of the program interface.
Parameters:
DescriptionComplete Alerts(optional)
Type: DescriptionAlerts. Contains a description of the procedure that will be called after closing the alert window with the following parameters: Additional Parameters - the value that was specified when creating the Alert Description object. If the parameter is not specified, then upon completion no procedure will be called.
Warning Text(required)
Type: String; FormattedString. Warning text.
Timeout (optional)
Type: Number. The time interval in seconds during which the system will wait for a user response. When the interval expires, the warning window will be closed. If the parameter is not specified, then the waiting time is unlimited. If the parameter is negative, an exception will be thrown. Default value: 0.
Title (optional)
Type: String. Contains the title of the warning window. Description: Displays a warning window, but does not wait for it to close.
Availability: Thin client, web client, thick client, mobile application (client).
Note: If any code must be executed after the user closes the warning window, it must be placed in a separate module procedure and described in a parameter.
2. Method Warning.
A warning window appears in the center of the program interface. However, if the configuration property Mode of UseModalities is set to Do Not Use , then the method does not work.
Availability: Thin client, web client, mobile client, thick client, mobile application (client).
3. Method ShowUserAlert.
ShowUserAlert(< Текст> , < ДействиеПриНажатии> , < Пояснение> , < Картинка> , < СтатусОповещенияПользователя> , < КлючУникальности> )
When using this method, a message appears in the lower right corner of the interface.
Availability: Thin client, web client, thick client.
4. Report method.
Report(< ТекстСообщения> , < Статус> )
Availability: Thin client, web client, mobile client, server, thick client, external connection, mobile application (client), mobile application (server).
5. Object Message to User.
Designed to store message parameters that need to be displayed to the user. If the message has not yet been shown to the user (this can happen when working on the server side, in a background job, external connection or Web services), you can get the accumulated messages using the method Receive Messages to User.
Properties: Destination ID(TargetID); DataKey; Field; DataPath(DataPath); Text.
Methods: Message; SetData(SetData).
The message appears at the bottom of the interface, in a line.
Message = New MessageToUser(); Message. Text = "Not enough nomenclature"; Message. Field = "Nomenclature. Quantity"; Message. SetData(DataObject) ; Message. Report() ;
