Each open configurator can and should, in the case of debugging in a file base launch its own separate dbgs process on a separate port. Those. if there is a need to open 2 configurators for debugging, then each of them needs to register its own port. Task Manager → Performance → Open the Resource Monitor → Network → the Listening to the Ports
When configuring debugging, you can additionally specify the base name, but it is used only if you are using a debug cluster. The same goes for the password for the debug server.
In the case of a mobile device, debugging can be enabled manually, it must be registered in the database connection settings, and it does not matter whether the mobile platform (on the left) or the mobile client (on the right)
In this case, the configuration update server is different from the debug server, and the update server also has its own debug server connected.
It is possible to debug configurations that are different from each other. For example, there is a central configuration, and it is also transferred to the device, then we changed the configuration, but did not publish it, but simply updated it. In this case, when trying to debug from a mobile device with an old configuration, 1C will try to simply get to the desired line number, which may already be changed or absent altogether.
Thus, debugging allows us to work more flexibly with databases, especially in the case of a file database. In addition, the window for connecting to debug items has changed. For example, now connections can be made to the following debug items
As you can see, there are many more of them now. But there were also debug templates, this is how their setup looks like:
Those. we can set up a separate template for connecting to a stationary 1C or to a mobile one and even indicate which users we expect debugging from, and users are indicated as a string, and not from a list, which allows us to control debugging even for those users who are not in the current database.
Thus, we have new mechanisms for more convenient debugging, and we no longer need to use tricks such as log files to identify problems.
But it is worth noting that, since HTTP debugging uses the usual HTTP protocol, every time the value of a certain variable is checked, a request is made to the web server, and, of course, if you want to get the value of a variable of the ValueStorage, which contains, for example, large photo, then 1C will start transferring this photo to the server, and it will be so every time you want to get the value of this variable. By the way, when debugging, 1C compresses traffic, so it makes no sense to specially place data in storage in order to archive it. But it is still better to do this for another reason, namely, the data can contain forbidden characters, so it is better either to put them in storage or to transfer them as Base64.
Now let's take a look at the basic settings for debugging the application and publishing to a web server:
Let's look at the mobile client first
We need to enable HTTP debugging and select a debug server.
Then we indicate the necessary data on the mobile device and set a stopping point on the stationary computer. For the test, a basic configuration was made, which includes a document and a little code
If everything is indicated correctly, then when the application is launched on the mobile client, we will receive the following result
And on a stationary computer, we will see a working breakpoint
The same result will be obtained when debugging on a mobile platform. However, nothing special needs to be configured. Except for the debug server when starting the application.
