Debugger is a tool built into the configurator. It helps to debug software modules created during the development of an application solution. The debugger allows you to track the sequence of execution of built-in language statements and view the values of variables.
Basic Debugging Features
- debugging applications running on remote computers, accessible via TCP/IP or HTTP protocol,
- debugging code executed by a worker process of a 1C:Enterprise 8 server cluster; it supports end-to-end call stack for client and server, and end-to-end step-by-step debugging client and server;
- debugging code executed in such types of connections as external connection, background job and WS connection?
- Debugging mobile applications.
Breakpoints
The debugger allows you to set a special marker on a specific line of a module - a breakpoint - upon reaching which the execution of the program module stops and control is transferred to the debugger. Breakpoints can be unconditional or conditional. When an unconditional breakpoint is reached, the execution of the software module stops in any case:
When a conditional breakpoint is reached, execution of the program module stops only if the specified condition is true:
The debugger supports the ability to disable breakpoints. In this case, the module line remains marked with a marker, but it does not have any effect on the execution of the module:
If there are a large number of breakpoints, it is convenient to use a separate window for working with breakpoints, which allows you to view and edit them in a single list:
Step-by-step execution
Once the control breakpoint is reached application solution transferred to the debugger, it is possible to further execute the module in several modes: step-by-step execution, execution of a function or procedure call, interruption of step-by-step execution of a function or procedure, execution of the module up to the line on which the cursor is located, or continuation of free execution of the module:
Viewing Expressions
During step-by-step execution, it is possible to view the values of the variables contained in the module and calculate arbitrary values. To do this, use a special window displaying the calculation result:
For embedded language objects, their property values are represented as a tree structure. Values that are strings, arrays, and collections of values can also be viewed in a separate window:
You can also view the current value of a variable by hovering your mouse over that variable. The current value will be shown as a short tooltip next to the variable.
Scoreboard and local variables
The results of calculations that need to be viewed during the execution of some part of the module can be displayed in a separate window - a scoreboard - in which it is possible to distribute all viewed expressions across four pages:
To conveniently view and change local variables, which seems to be the most common task, there is a command Local variables. It opens a table that is already automatically filled with all local variables.
Changing Variable Values
Values of primitive types can be changed directly in the cell Meaning.
And to change other values, you can use the expression input window.
Contextual help is fully functional in this window.
Call stack
The debugger allows you to use a call stack, which shows the sequence of procedure and function calls that led to the module line that is currently being debugged:
By double-clicking on a procedure name in the call stack, you can jump to the corresponding procedure line.
Stop by mistake
The platform provides the ability to use the Stop by error mode. In this mode, debugging can be stopped either for every error that occurs, or for an error that contains a substring specified by the developer. Substrings of the errors of interest are specified in the debugging settings.
During debugging, this setting will only stop debugging when errors involving division by zero occur.
8, there is a need (as discussed below) for a significant reworking of the debugging procedure. This was reflected in version 8.3.7.1759. Firstly, a universal interface was created for this procedure, and secondly, this change ensures further development the program itself. After all, now you can work with debugging not only through the Configurator, but also using Development Tools. Let's look at how to enable debugging on the 1C server starting with the new version.
Using the new protocol
The previous debugger, which was implemented in previous versions, managed client and server applications using the TCP/IP protocol.
Currently, the use of such a protocol has begun to limit the access of the 1C: Enterprise program to the Internet and has created inconvenience for work mobile applications.
Therefore, for free access to information bases that may be located outside the local network, the flexible HTTP protocol has now been adopted.
New architecture
Previously, when performing configuration debugging, an employee had to connect to the information base. To do this, it was necessary to give him administrator rights.
In the new version in direct connection there is no need for databases - it is enough to simply have the same database as the client. And you can load it from a file.
Mobile applications
Using the HTTP protocol, it is now possible to debug server data, client data, and applications.
Other changes
WITH new version In the debugging procedure, it is possible to change values for local variables; a new quick view window has been implemented for this purpose.
The calculation mode has been changed to asynchronous, allowing you to continue working without waiting for results.
Debugger in Development Tools
Interaction with the new procedure is carried out in a specially designed universal software interface. On the one hand, this interface is used by the Configurator. On the other hand, it is implemented in the new 1C:Enterprise Development Tools environment.
What does it look like now
After changing the program, the procedure occurs according to the following scenario:
Now it involves not only the debugger and items, as was previously the case. Now an additional element has been introduced into the chain - Server.
Not only is it added - it serves as the main element of information exchange between the debugger and objects. And the exchange itself occurs through messages lined up in a queue.
And since this exchange is carried out via the HTTP protocol, it now does not matter where exactly the data may be located.
Calls to the server are formed from the debugger and objects in the form of additional connection requests. When they appear, appropriate responses are sent to them.
Enable debugging in different scenarios
For the application developer, there have been no changes. The significant difference is that the new mechanism must be enabled. After all, it is now disabled by default.
Let's look at what happens when the mode starts if we choose one of two scenarios.
File script
At the beginning of the file version, you must specify in the configuration settings the use of a new mechanism - “Debugging via HTTP protocol”.
Then the Configurator will automatically prompt you to use local server. This condition must be accepted and the program restarted in Configurator mode.
After this, the newly launched Configurator will save our chosen one during the next session. new way. But for the same information base. Therefore, when accessing another infobase, it also needs to be enabled.
The enabled mechanism will now automatically launch the Debugger Server, which is a special application dbgs.exe. It is reflected in the Task Manager window.
The value of the ownerPID parameter will correspond to the ID of the application that is bound to it.
When you start a debugging session through the Configurator, the server connection will occur automatically. And the connected objects will be reflected in it.
If the 1C program was activated without the new mechanism, then you will need to enable debugging on the 1C server manually. Only now you will need to specify the server address:
Go to Service - Options
It is located in the item settings:
Go to Connection - Settings
When using a file script with several databases at the same time, you need to take into account important nuance, - each of the Configurators (with the HTTP mechanism enabled) sends its Server:
Therefore, if several Configurators are open, then to connect the Client you need to specify the correct one.
Client-server scenario
Debugging on a 1C server using a client-server scenario, as in the previous case, begins by launching the mode. This specifies the use of the new HTTP mechanism. This is done this way:
ragent.exe -debug -http
When it starts, the debugger automatically starts after it.
The value of the ownerPID parameter will correspond to the identification number of the 1C cluster manager.
The program will generate a proposal to use the cluster debug server now (and not a local one as in the previous scenario). We agree and restart it.
In the future, everything will go like a file script. Only when starting the Configurator server base the local debugger server will no longer start.
We hope that our publication helped you figure out the problem of how to enable debugging on a 1C server.
In fact, a module consists of functions and procedures. These are lines of the program, united by a name. Inside one function, another can be called, including one located in another module.
The program is written in 1C Configurator mode. The program runs in Enterprise 1C mode.
How is the program executed?
How is the program executed?
First, the first time a module is accessed, the program lines located at the very end of the module, not enclosed in a function or procedure (if any), are executed.
Second, a function or procedure call must occur. This can be done while executing some other module. If this is a form module or an object module, then the module has handlers. Handlers are functions that are called automatically by the 1C platform when a certain event occurs. For example, “when a form is opened,” the corresponding handler is executed (if it has been assigned).
When it becomes necessary to execute a function, the platform starts executing it from the first line of the program inside the function and goes sequentially down to the end of the function, line by line.
The exception is that if another function is called, then the platform moves on to executing it and only then returns back from where it came.
What is 1C debugging?
When a program is written, the programmer can only guess how it should work. When it starts to work for real, the user enters some data into the form fields, certain conditions and settings begin to apply, and the program may suddenly begin to work not exactly as the programmer intended.
At the same time, specific decisions made by the program, comparison results in “If” conditions, and so on are interesting.
For these purposes, 1C debugging is used. Its general idea is that the programmer can set a breakpoint at required line program and the program will stop execution on it - to pause. At this time, you can see what values the variables and other parameters took.
The programmer can press a button in the 1C debugger and the program will continue its execution, but not entirely, but only one line. And then it will pause again.
This way you can catch problem areas of the program.
Start debugging 1C
Since the program is written (and located) in the configurator and executed in Enterprise mode, to use 1C debugging you need to have 1 configurator and 1 debugged Enterprise mode:
- running
- connected.
Enterprise mode can be launched immediately with 1C debugging. To do this, you can use the corresponding button in the configurator as in the picture.
Or use the menu Debugging/Start debugging or Debugging/Start debugging/Select 1C client option.
If you already have 1C running in Enterprise mode and you want to connect to it, you need to do the following:
1) In the 1C client in Enterprise mode, in the Service/Options menu on the “Service” tab, check the “Debugging in current session allowed"
2) In the configurator, select the Debug/Connection menu item
3) In the window that opens, highlight the desired client with the cursor and click the Connect button.
Breakpoint 1C (breakpoint)
After you have connected the configurator and the running client with 1C debugging (that is, “connected with the 1C debugger”), all actions of programs from the modules of this client are performed under the control of this configurator.
To start watching how execution occurs, you need to set a breakpoint in the required place.
To do this, you need to open the module that you want to debug. Next, find the required procedure. You can set a breakpoint in the following ways:
- Left-click on the gray bar to the left of the module texts
- Press F9
- Select the Debug/Breakpoint menu item.
As a result, a red circle will appear, as in the picture. This is the breakpoint. As soon as a program running in Enterprise mode reaches this line, it will stop executing and pause.
When this happened (the program paused), there will be a yellow arrow on the line where it is currently “executing”.
To view the value of a variable at this moment, highlight the required variable with the cursor and press Shift + F9.
To execute one line (that is, go to the next line), click the corresponding button as in the picture or select an item from the 1C Debugging menu.
Conditional breakpoint
In addition to the usual breakpoint, you can set one that will only fire if the condition specified in it is met. It is called “Breakpoint with condition” - see the item of the same name in the 1C Debugging menu.
For example, a program has a loop that repeats many times. We can set a breakpoint that will trigger on certain repetition loop (“loop iterations”).
Error breakpoint
For such purposes, there is a breakpoint that is triggered when any error or errors of a certain type occur while working “in the 1C debugger”.
Note that this breakpoint even catches errors that occur in .
How to start debugging on a 1C server...
By default, when using client-server architecture 1C:Enterprise 1C code debugging mode only works on client side. Server procedures and functions are not visible to the client machine.
To enable the use of debugging on the 1C server, you must perform the following steps:
1. Find and stop the “1C:Enterprise Server Agent 8.3” service in the service manager (for version 8.3).
2. Open editor system registry. You can use command line or the Start menu tool – Run... and the command regedit.
3. Find the branch in the registry:
- For version 1C 8.1
- For version 1C 8.2
- For version 1C 8.3
4. Change the ImagePath property, add the “-debug” directive to the end of the line. You will get the following property line: “C:\Program Files (x86)\1cv8\8.3.6.2152\bin\ragent.exe” -srvc -agent -regport 1541 -port 1540 -range 1560:1591 -d “C:\Program Files (x86)\1cv8\srvinfo" –debug
After this, the 1C server code can be safely checked with a debugger and breakpoints can be set wherever required.
Loading...
