1s 8.3 pop-up message to the user. Process status notification
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.
Options:
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.
To 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 may happen when working on the server side, in 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. To report() ;
The development is designed to notify users, both selectively and all, you can also simply write messages or conduct correspondence between users.
Development is a register of information and a change in a module of a managed or regular application.
To trigger an alert, you must add an entry to the information register, users will receive notifications during the period specified between the start and end of the notification time.
MANAGED APPLICATION
REGULAR APPLICATION
Alert window shown in the user program blocks the entire interface and users working in this moment the program will not miss the notification and will read it accordingly.
MANAGED APPLICATION
REGULAR APPLICATION
Register list
In the list of notifications, you can view who received the notification and who read it.
MANAGED APPLICATION
REGULAR APPLICATION
To implement the development in your configuration, you must:
- Set the ability to edit the configuration.
- Compare with the configuration supplied in this publication. A "User Alerts" information register will be added and an entry in the regular or managed application module, depending on the application's primary launch mode.
A regular or managed application module entry differs:
MANAGED APPLICATION
Implementation of the development is free and completed within 10 minutes.
Free technical support for 30 days.
IN
The development is intended for platform 8.3, various standard and non-standard configurations, in thin, thick client and web client modes.
Independent modification is possible, the code is open for editing.
Reasons to buy
A very convenient option for alerting, notifying 1C users about technical work, modifications to configurations, updates, the ability to correspond between 1C users within the framework of the 1st program.
Advantages
1) 100% delivery of alerts to all users, unlike analogues.
2) Ability to send pictures.
3) View user activity in the list of messages (who was delivered, who read).
4) The ability to write a response to the person who sent the notification.
5) Does not affect other objects when updating configurations with the editing option installed.
Money back guarantee
Infostart LLC guarantees you a 100% refund if the program does not correspond to the declared functionality from the description. The money can be returned in full if you request this within 14 days from the date the money is received in our account.
The program has been so proven to work that we can give such a guarantee with complete confidence. We want all our customers to be satisfied with their purchase.
During the lesson we: created a base, created processing, created a form.
Now we will tell you 5 methods of messages from 1C “Hello, world!”
Not everyone knows about at least two methods :)
How and where to write the program text?
Switch to the tab of the window with the “Module” form. You will make sure that you already have some text there (“Procedure…”).
If there is no text, then:
- In the thick client you added the form to processing incorrectly, repeat from the beginning
- IN thin client You forgot to add a button, try again from the beginning.
Inside the text there is a line:
// Insert the contents of the handler
Your task is to erase this line and enter the program text in its place. After that, save the processing and open it in enterprise mode.
When you click Execute, the actions you entered will now be performed.
Now let's move on to the methods themselves!
Message in 1C, method 1 - the easiest
So you should instead of the text “// Insert the contents of the handler.” write the program text.
Report("Hello world!");
Actually that's all :)
The message in Enterprise mode in the thick client will be at the bottom of the 1C window, in the thin client - on the right in the processing window.
This is the simplest method, very widely used by programmers.
Message in 1C, method 2 - also simple
Alert("Hello world!");
Actually that's all :)
The message in Enterprise mode in both client options will be in a pop-up window.
Message in 1C, method 3 - appeared only in 1C version 8.2
ShowUserAlert("Hello, world!","Hello indeed!");
This method appeared only in 1C version 8.2. This is a pop-up window in the lower right corner of the screen that goes away over time.
Message in 1C, method 4 - programmer
Throw Exception "Hello, world!";
There can be an error when executing any program. Sometimes this error can be calculated in advance (for example, you need to calculate a = b/c and at the time of program execution it becomes known that c is equal to 0).
In this case, there is a way to report the error using this method.
Message in 1C, method 5 - technologically advanced, only for standard configuration
General Purpose.ReportError("Hello, world!");
A 1C programmer must know not only those programming methods that are in the 1C platform, but also those that are in typical configurations.
Beginners, when trying to add any standard configuration, begin to reinvent the wheel.
Here's a perfect example. This feature is present in many standard configurations (thick client only!). It would seem that the result is equal to the action of method 1.
However, no - in some configurations (for example soft starter), error messages are duplicated in the log. Also when additional settings the message looks completely different.
So, now you can feel like a real programmer!
This is exactly what 1C programming is. Of course, real programming is much more complex and requires a lot of knowledge, but you now have a general idea.
Good luck!
P.S. IN pdf versions The lesson contains screenshots to make it easier to make your own experience.
P.P.S. The lesson includes 5 videos with examples of creating a base for programming, creating processing, programming in a thick and thin client.
Implemented in version 8.3.10.2168.
We have improved the user notification mechanism. Now it is equally convenient to use both in the thin client and in the web client. We changed appearance notifications and added a number of new features to them.
Show multiple alerts
In the old implementation, only one alert was displayed on the screen at a time. The new alert overlapped the previous one. Thus, if several alerts were displayed in a row, there was a high probability that the user would not have time to read the previous alert, since it would be covered by the next one.
Now, in most cases, up to three alerts can be displayed simultaneously:
This is true for the thin client, thick client, and web client running in browsers Internet Explorer And Google Chrome . Browsers Safari And Mozilla Firefox allow you to display an unlimited number of alerts, and the browser Microsoft Edge shows one last alert, but it contains Action Center, into which all alerts are duplicated.
Displaying alerts when the application window is inactive
Previously, in the web client, alerts were displayed only in the active browser window. If the user switched to another window or another application, he did not see the alert. Now, when using the web client, notifications are displayed on the screen even when the application window is minimized or inactive.
When the method is called for the first time ShowUserAlert() in the web client Google Chrome, Mozilla Firefox And Safari The browser will ask the user for permission to use notifications. The user can allow their output for this application, or prohibit.
If the user disables the display of notifications, then the new type of notifications will be used, but they will be rendered inside the browser window.
Alert Center
To prevent notifications from disappearing forever, we have implemented alert center. And for the alerts themselves, we have implemented a new property - User Alert Status. It can take two meanings: Information And Important.
Alerts with status Information are displayed on the screen and disappear after 10 seconds (in the browser Microsoft Edge– after 4 seconds). Alerts with status Important behave exactly the same, but they are saved in the alert center.
The Alert Center is accessible from the toolbar. The fact that there are new important alerts is indicated by an orange dot next to its icon.
The Alert Center displays important alerts that the user has not yet responded to by closing or taking an action related to the alert. Alerts are listed in the order they appear, with the newest on top. This way, even if the user leaves the computer, he will not miss important notifications.
An alert can be removed from the list using the clear button. If there is some action associated with the alert, then after clicking on the alert text, it will also disappear. Team Clear alerts removes all alerts from the list. However, if actions were associated with alerts, they are not executed.
Perform actions when pressed
In the old implementation, the only action you could perform when you clicked on an alert was clicking on the navigation link. It was passed to the method as the second parameter.
<Текст>, <НавигационнаяСсылка>, …
Now we have expanded the capabilities of alerts, and in the second parameter you can pass not only a string with a navigation link, but also a description of the alert.
ShowUserAlert(<Текст>, <ДействиеПриНажатии>, …
The alert description indicates the procedure that should be performed when the alert is clicked.
Appearance
In the thin client in the interface option Taxi the notification style will be as close as possible to the browser notification style Google Chrome using Notifications API.
If the interface option is used Version 8.2, then the alert style and behavior remain the same.
In the web client, the appearance of alerts is determined by the browser used. By and large, the alerts will look the same as in the thin client, but each browser has its own characteristics. For example, you can compare how the same alerts will show Internet Explorer And Mozilla Firefox.
Besides this, there are other features. For example, in the browser Internet Explorer Only alerts displayed inside the application window are supported. And in the browser Safari parameter Picture is not supported and alerts are shown at the top of the screen.
The article continues the series of articles “First steps in development on 1C”.
In it we will look at the methods of informing the user that are present in the 1C:Enterprise platform 8, and also focus your attention on some features of the operation of these mechanisms; these features are related to the mode of use of the modality.
Applicability
The article discusses the functionality:
- Interface in the “Version 8.2” version for the configuration developed on the 1C:Enterprise platform 8.2.19.130
- Taxi interface for configuration developed on the 1C:Enterprise platform 8.3.4.496 to 8.3.9+
- Taxi interface for a configuration developed on the 1C:Enterprise platform 8.3.10-8.3.11
How to display a message to the user in 1C
Displaying messages in user mode solves a number of problems:
- reflection of the progress of the current process (showing the stage of execution of the process; showing the calculated values obtained during the operation of the algorithm);
- displaying errors to the user for possible correction;
- issuing recommendations;
Message types:
- Terminators, which stop the execution of the program and do not allow it to continue until the user reads this message and performs certain actions. For example, the user will be presented with a question on the screen that will need to be answered Yes or No. Until the user responds, the program does not execute further actions;
- introductory messages that are simply displayed to the user and allow further work (i.e., used in alert mode).
Termination messages should be error messages, and introductory messages: recommendations, messages about the current stage of the process and display of calculated values (debug print).
Introductory messages are intended to provide the user with some information.
It is necessary that the user familiarize himself with it and, possibly, take some actions that are described in this message.
It is very important that the user actually reads these messages, so they should only contain important information.
Test and debugging messages should not be issued to the user, because sooner or later he will begin to ignore absolutely all messages.
In the concept of a managed interface, the approach to issuing a message has changed somewhat. It is now tied to the form in which it originated. It can no longer be closed so that the text is completely invisible.
You cannot unpin a message box from a form.
Function syntax:
To report (<Текст сообщения>, <Статус>)
Those. the first parameter is the text itself.
The second parameter (message status) is optional. You can specify values for the status: Normal, Important, Very important etc.
From given value depends on which icon will be located next to the message. However, this only works in the normal interface.
In the managed interface concept, the icon is always in the form exclamation point, it cannot be redefined.
The fact is that if a message is generated at the time of writing a directory element, the following situation may occur.
User clicks on a button Save and close, in this case the message is displayed in the corresponding window (on the right of the form).
But the form closes instantly, and the user will not see that any information was displayed for him.
Therefore, in the concept of a managed application, it is recommended to display introductory messages using so-called alerts. An example of incorrect use of a function To report presented in the figure.
However, the function To report can be used to display information about certain errors, for example, at the time of document posting.
In this case, the system can be informed that the form does not need to be closed and show the user what errors occur when posting the document.
Function To report fully supported in Platform 8.3. It can be used, and it will work (both in the file version and in the client-server version).
But it should also be noted that the function To report There is a further development - this is a message class for the user, which allows, in addition to displaying a message, to bind it contextually to any form elements.
For example, an error message can be tied to a form element, which is very clear to the user. We will return to consider this issue a little later. Function To report there is an interesting feature.
Thus, the program code in Platform 8.3 can be executed both on the Client side and on the Server side.
In this case, the client program code is responsible for interaction with the user, i.e. On the client side, forms are opened and reports are displayed.
Various dialog documents are also displayed only on the client. They cannot be executed on the server because the server does not have the ability to interact with users.
But the function To report can be executed both on the Client side and on the Server side. In this case, the use of the method To report on the Server does not mean at all that the message will be displayed on the Server, there is simply nowhere to display them.
This means that if we display a message in the server procedure using this method, they will accumulate in some buffer and they will be displayed on the screen only when the server procedure ends and returns to the Client.
At this point, the system will request data from the buffer and display it on the screen.
The same feature applies to the class Message to User. The figure shows an example of using the method To report on the Server side.
As a result of using the method To report on the Server side, messages were displayed on the screen on the Client side.
An alert mechanism is needed to inform the user that “something” has happened in the system and that “something” requires the user’s attention. Alerts are generated by two scenarios:
- By the platform itself when interactively recording or changing an object
- By the developer when calling a method in the code .
The notification itself is a small window that appears, as a rule, in the lower right corner and informs about the completed action. Within a few seconds it gradually fades and disappears. At the same time, if you hover your mouse cursor over the notification, it does not go away and you can read it carefully.
In addition, alerts can be accessed in the corresponding area of the information panel (the “History” button at the bottom left of the application form in the “Version 8.2” interface option).
To create your own alerts, you must use the global context method ShowUserAlert(). Its syntax before version 8.3.10 is presented below:
ShowUser Alert (<Текст>, <НавигационнаяССылка>, <Пояснение>, <Картинка>)
The first parameter contains the text that will be displayed in the notification.
Then, as the second parameter, you can pass a certain navigation link to an element information base(the element that corresponds to the text of our message). When a user clicks on an alert, the link will be followed.
Using the third parameter, you can pass an explanation for the message, i.e. some extended description.
You can also assign a picture that displays the notification status.
It should be noted that all these parameters are optional. Below is an example of use this method(in the configurator and in user mode in the “Version 8.2” interface option).
In the version of the platform 8.3.10.216 for the “Taxi” interface, the notification mechanism was significantly improved in order to improve the usability of both the thin and web clients. For this reason, the parameters passed to the method have also changed ShowUserAlert(). Now the syntax looks like this:
ShowUserAlert(<Текст>, <ДействиеПриНажатии>, <Пояснение>, <Картинка>, <СтатусОповещенияПользователя>, <КлючУникальности>)
It can be seen that the second parameter, previously called Navigational Link, got a new name ActionWhenClicked. This is due to the fact that it is now possible to send not only a string with a navigation link, but also a description of the alert. This is illustrated in the screenshot below:
As can be seen from the example, we now have the ability to programmatically process a click on a notification window, according to the logic that is necessary.
Next parameter User Alert Status appeared for the first time. It indicates the status of the alert (Information or Important).
In the case of the Important option, if the user has not responded to the message, then after it is hidden from the screen, it can be read through the Notification Center (more about it below). In the case of the Information option, the notification is deleted without being stored in this center. Let's rewrite the code from our example as below:
After executing the command, we get approximately this view of the application window:
A button with a bell icon has appeared in the toolbar, which calls up the above-mentioned Notification Center. It accumulates new important alerts to which the user has not yet responded.
If there are any alerts in the Center, a small orange dot appears next to it to attract the user's attention. The user can open the Notification Center, read the text and, if necessary, take some actions.
From the Center, the alert is cleared by clicking on the clear button, but if there is some action associated with the alert, then as soon as the user clicks on the text of the message, it will also disappear.
And finally, the last parameter added was Key of Uniqueness. You can use it to find the alert displayed on the screen and change it. If there is no alert with this parameter, a new alert will be shown.
As you can see, the possibilities provided by the corresponding method have become even greater! But these are not all the changes in the notification mechanism.
As you may have already noticed, their appearance has changed. Alerts now look more modern and ergonomic, but they cannot be moved around the screen or resized. Please note that in our example, the notification text simply did not fit entirely in the window itself, and the user will be able to read it in full only by opening the Notification Center. Therefore, you should not write a large amount of text in the notification text.
New features also include the simultaneous display of up to three alerts on the screen.
This concludes our acquaintance with the software generation of alerts. However, remember that alerts are generated not only by the developer programmatically, but also by the platform itself at the time of interactive recording or changing an object. And often this fact causes misunderstanding primarily among novice users: why are these service alerts needed, which, by the way, cannot be disabled?
Let's imagine this simple situation: the user has set a filter in some list for convenience. Let's say he did this in the form of a list in the Nomenclature directory. Then, after some time, I decided to introduce new element with the name “Chair”, which does not match the previously installed filter. Enters it, writes it down and...? And he doesn't see it on the list. What will the average user do? Of course, he will enter it a second time, but will not see it again. This may be followed by a third, fourth, fifth time. When he gets tired of entering the same thing over and over again, he will finally ask you: where does everything go?
This is precisely why the platform displays these service alerts, informing the user that their action has been completed. In our example, at the time of interactive recording, the user will see the following notification:
Termination messages
Termination messages are those messages that will not allow work until the user performs certain actions, i.e. until it processes the message.
We will talk about the possibility of using termination messages in Platform 8.3 a little later (in Lately They try not to use them, so the example considered is more relevant to Platform 8.2).
There are two methods for issuing termination messages Warning And Question. Warning differs from Question because it has a single button OK.
A question may specify different sets of answer options ( Not really, YesNoCancel, OK, OKCancel, RepeatCancel, AbortRepeatSkip), which are specified using the parameter.
Let's display some warning using the line (for example, in a managed application module):
Warning(“The base will now be open”);
To open a managed application module, select the object in the configuration tree Configuration, call the context menu and select the item Open a managed application module.
In this case, when the application is launched, a window will be displayed that is modal. A modal window overlaps all windows that exist in the application. Until we process this window, no further actions are possible.
The function works in a similar way Question.
Syntax:
Question(<ТекстВопроса>,<Кнопки>,<Таймаут>,<КнопкаПоУмолчанию>,<Заголовок>,
<КнопкаТаймаута>);
Only the first two parameters are required. For the second parameter, the data type is composite ( Dialogue ModeQuestion or ListValues). Third parameter ( <Таймаут> ) characterizes the time interval in seconds during which the system will wait for a user response.
When the interval expires, the question window will be closed. Similar parameter( <Таймаут> ) is also available for the function Warning.
As an example of using the function Question You can use the following code, written in a managed application module:
Please note that these methods ( Warning And Question) are not available on the Server. And this is logical, because interface methods cannot be executed on a Server where there is no user.
Features of use modal windows in Platform 8.3
In platform 8.3, there are operating modes with and without modality. The default setting is Do not use modality mode.
In this case, the use of termination messages is impossible. If it is necessary to use termination messages (functions Warning And Question) you should change the value of the configuration property on Use.
The modal window is displayed at the very top and blocks work with other windows until the actions with the modal window are completed. In addition, execution stops program code at the place where this window is called. Code execution will continue only after the modal window is closed.
Firstly, problems with using modal windows arise for mobile application. Secondly, in the browser, window modality is implemented using separate pop-up windows.
Pop-up windows are often disabled by default browser settings. The user has to be forced to set the permission for these windows.
Browsers for tablet computers and for phones in most cases they do not support pop-ups at all.
To replace functions Question And Warning new methods have been developed: ShowQuestion, ShowWarning.
These methods allow you to call a window, but do not stop the execution of the program code. Technically, this is achieved by forming a pseudo-window inside the parent window. The pseudo-window does not overlap the parent window. After opening such a window, the code continues to execute.
Receiving and processing user-entered values is carried out in a separate procedure, which is called when the dialog box is closed.
Function syntax ShowWarning:
ShowWarning(<ОписаниеОповещенияОЗавершении>, <ТекстПредупреждения>, <Таймаут>, <Заголовок>)
Parameter <ОписаниеОповещенияОЗавершении> (optional)
Data type: DescriptionAlerts.
Contains a description of the procedure that will be called after the warning window is closed.
Function syntax ShowQuestion:
ShowQuestion(<ОписаниеОповещенияОЗавершении>, <ТекстВопроса>, <Кнопки>, <Таймаут>, <КнопкаПоУмолчанию>, <Заголовок>, <КнопкаТаймаута>)
The first three parameters are required.
Below is an example of using the function.
Class MessageToUser
Basic convenience of the message class Message to User is that this is a contextual message (unlike methods Warning And Question).
Messages can be tied to a specific screen element. This object is also available on the Server.
It should be noted that, firstly, this object needs to be created. For example: Message = New MessageToUser;
Thus we create an instance of this object.
Secondly, you need to specify the message text in a separate property.
Thirdly, in the property Field you can specify which form element this message must be tied.
Attention! To bind to the desired form field, pay attention to the initialization of properties PathToData And DataKey. For a document, when placing code in an object module, you can write:
Message.DataPath = “Object”;
Message.DataKey = ThisObject.Link;
To open the document module, in the object (document) editing window, go to the tab Other press the button Object module.
For the experiment, we will place the code in the object module of a document.
Below is the result obtained in user mode for Platform 8.3.
It should be noted that messages output using the new system object Message to User in the general case they are not terminating. Those. the system will allow the user to continue further actions without responding to the displayed messages.
But, firstly, these messages are quite noticeable. Secondly, messages are usually displayed to the user at the time of recording elements of directories or posting documents, i.e., when some checks are performed. And if errors were detected, the user will see these same messages.
Accordingly, when errors are detected, the transaction is canceled, i.e. writing a directory element is prohibited, or posting a document is prohibited.
Thus, a kind of emulation of the termination message occurs. Because the action is canceled until the user reacts to the entered message, it will be impossible to complete the action, for example, posting a document.
But, on the other hand, it is possible to close the document without conducting it, without reacting to the message in any way. Therefore, these messages to the user are not terminating.
Process status notification
There is a special function with which you can display the approximate progress of a process.
Syntax: State(<ТекстСообщения>, <Прогресс>, <Пояснение>, <Картинка>)
Options:<ТекстСообщения>And<Пояснение>– optional, type – Line.
The text is displayed on a special status bar.
<Прогресс>The parameter is also optional, but visual.
Type: Number. Progress indicator value (from 1 to 100).
<Картинка>also an optional parameter.
When processing any event, periodic calls of a function like:
In this case, the labels may change, and the values of the Progress parameter may change.
A function can be called from one procedure (function) or from several. This way you can track the execution status of the process.
If you want to take a closer look at the notification mechanism, stop right now and read our new article, Displaying the progress of long-running operations in 8.3.10. It explains, no longer at the level of a beginner, all the subtleties and pitfalls of the operation of this mechanism.
We are finishing our introduction to ways to inform the user. We hope that you have an understanding of in what situations one or another method should be used.
I would like to once again draw your attention to the fact that if your configuration (version 8.3.3+) involves working using a web client, then:
- at the configuration level the modality mode setting must be set to “Do not use”
- The code must use methods of the asynchronous user interaction model. Such methods begin with the words Show or Begin.
You can read more about refusing to use modal windows in the 1C:Enterprise 8.3 platform in the final article of the series. And we move on and, finally, begin to study the long-awaited Taxi interface, which has already been mentioned more than once in our materials.
