This is another article from the series "First steps in development on 1C". It continues the topic of the previous article devoted to the specifics of working in the configurator.

In this article, we will consider a special tool that facilitates the development and debugging of program code on the 1C: Enterprise platform, which is called the Debugger. After studying the article, you will find out:

• What is a debugger for and how do I use it?
• What are breakpoints, how and why should you set them?
• How to step through the code and why is it needed?
• Where can I look at the values ​​of my variables, as well as calculate the values ​​of expressions?
• What is the call stack for and how to view it?
• How do I stop the execution of a program code by mistake?

Applicability

The article discusses the 1C platform version 8.3.4.365. The current current version of the platform contains richer debugging mechanisms, but this does not make the presented information obsolete, since all the mechanisms and techniques of debugging described in the article remained the same.

Using the debugger in the 1C: Enterprise 8 system

The 1C: Enterprise 8 system contains a built-in program code debugger.

The debugger is a special tool of the Configurator that allows you to analyze the work of the program code. This article discusses some of the debugger features that are most commonly used by developers.

To analyze program code using a debugger, a special tool is used called breakpoint.

Breakpoint - the place where the system stopped in the program code, marked with a special marker (Fig. 1).

Rice. 1. Breakpoint

When a breakpoint is triggered, it becomes possible to step through the program code and analyze the values ​​of variables.

Setting breakpoints

Setting a breakpoint on a specific line of the program code is carried out by double-clicking the left mouse button in the left area of ​​the program module, which is highlighted in gray.

It is also possible to set a breakpoint with the command on the configurator toolbar or with the button F9... Clearing an existing breakpoint is done in a similar manner.

To set a breakpoint at the end of a procedure or function, you must set a breakpoint on a keyword End of Procedure or EndFunction.

You can disable a breakpoint temporarily without removing it from your code. To turn off the breakpoint, execute the command Disable breakpoint on the toolbar or press the keyboard shortcut Ctrl + Shift + F9.

To view all breakpoints, you need to execute the main menu command Debug - List breakpoints or press the keyboard shortcut Alt + F9... In the opened form Breakpoints you can temporarily disable or remove breakpoints (Fig. 2).

Rice. 2. List of breakpoints

To delete all breakpoints, you need to execute the command of the main menu of the configurator Debugging - Remove all breakpoints.

Conditional breakpoint

A conditional breakpoint is necessary to stop the execution of the program code when a certain condition is triggered.

To set a breakpoint with a condition, you need to execute the command of the main menu of the configurator Debugging - Conditional Breakpoint... The Stop condition form will open. In the input field you need to enter the necessary condition (for example, the value of any variable in the program code) and click the button OK(Fig. 3).

After starting the system in debug mode, a breakpoint will be triggered when the break condition is met. You can verify this using the form Scoreboard(Fig. 3). Working with a form Scoreboard will be discussed below.

Rice. 3. Setting a breakpoint with a condition and the result of its processing

In order to start debugging the program code, you need to set breakpoints and run the application in debug mode. To start debugging, you need to execute the command of the main menu of the configurator Debug - Start Debugging(F5).

After starting the application in debug mode, you must ensure that the breakpoint is triggered. Different scenarios are possible here. For example, a breakpoint is set in the document form module in the standard event handler OnOpen ()... In this case, the breakpoint will be triggered when the form of any document is opened in user mode.

A breakpoint can be set in an arbitrary procedure or function that a developer has created. In this case, the breakpoint will be triggered after calling this procedure or function from a specific line of code.

After the breakpoint is triggered, the system stops the execution of the program code and it becomes possible to use various debugger functions, such as: step-by-step execution of the program code, use of the form Scoreboard etc.

Step-by-step execution of program code

For step-by-step execution of the program code, use the commands that are available in the main menu of the configurator in the menu Debugging... It is convenient to use hotkeys for these commands.

Step into (F11)... If the next operator of the program code calls a procedure or function, then it is executed step by step, otherwise, the next operator is executed.

Step through (F10)... If the next statement of the program code calls a procedure or function, then it is executed completely without going inside. Then the next statement is executed.

Go to cursor (Shift + F10)... Operators are executed from the current executable line to the line of program code where the cursor is located.

Using forms Scoreboard and Expression

To view the values ​​of variables and calculate the values ​​of expressions while stopping the program code, use the forms Scoreboard and Expression.

The form Scoreboard called by the command of the main menu of the configurator Debugging - Scoreboard or a keyboard shortcut Ctrl + Alt + W... The scoreboard can record the values ​​of any variables and analyze how they change during the execution of the program code.

The scoreboard has four tabs. By default, bookmarks are disabled. To include bookmarks in a form Scoreboard you need to call the context menu and set the flag Bookmarks(Fig. 4).

Rice. 4. "Scoreboard" form with included tabs

To calculate the values ​​of expressions at the time of stopping the program code, use the form Expression... To open this form, use the command of the main menu of the configurator Debug - Calculate expression or keyboard shortcut Shift + F9(Fig. 5).

Rice. 5. Form "Expression"

In the Expression box, you enter an expression in the built-in language. The expression value can be obtained by clicking the button Calculate... In field Result the value of the expression is displayed. The expression can be displayed in the scoreboard by clicking the button Include in the scoreboard.

To view the values ​​of a collection (for example, table of values, list of values, array), you can use the command Show value in a separate window or key F2.

Viewing the call stack

Call stack- a form that allows you to track mutual calls of procedures and functions during the execution of program code. The call stack is displayed by the command of the main menu of the configurator Debugging - Call Stack or a keyboard shortcut Ctrl + Alt + C... Out of shape Call stack you can go to the corresponding procedure or function (Fig. 6).

In the form, you need to set the flag Stopping by mistake and run the application in debug mode. The execution of the program code will be stopped at the line where the error occurred (Fig. 7).

Using the debugger capabilities described in this article, a developer can analyze both our own program code and the program code of typical solutions firm "1C".

As practice shows, it takes a long time to find errors in the program code without a debugger. Therefore, special attention should be paid to mastering the debugger.

As mentioned above, the debugging mechanism has been significantly expanded in subsequent versions of the platform. For those who want to get acquainted with a detailed description of these innovations, we recommend that you read the relevant material in the blog of the platform developers themselves.

In conclusion, we note that the configurator is a full-fledged and until recently the only application development environment on the 1C: Enterprise 8 platform. It has a very rich functionality designed to help the developer in solving his daily tasks.

In the 8.3 revision, a lot of small usefulness for the developer has been added to the configurator. And in the next article we will definitely get to know them.

In this article, I'll cover the basics of working with debugging in. What is debugging and what is it for? It is often necessary to understand how a particular piece of code works, and what values ​​various variables contain. has a debugging mechanism for these purposes. In this article, we will cover the main points of working with debugging.

In order for the program to stop at a certain place, you need to set a breakpoint. To do this, place the cursor on the desired line and click on the left field. A red circle appeared on the left. A breakpoint can be set using the main menu

Or using the context menu

At this point, the program will stop to allow the developer to get acquainted with its behavior.

I draw your attention to the fact that a breakpoint must be set at the place in the code where some operator is written. Or variables are implicitly declared.

There are several options, we will consider them all separately.

The first option, you can just go through the code without going into any procedures and functions. To do this, use the "Step Through" button or the F10 key.

Keep in mind that if debugging transfers control to some interactive function where user intervention is required, then either the program will immediately transfer you to 1C Enterprise, or debugging will freeze, and then you will have to switch to 1C Enterprise on your own.

The second way, you can go through the code and go into all the written procedures and functions to see how they work. To do this, press the "Step B" button, or press the F11 key.

If we need to exit a procedure or function without waiting for its execution, then we need to press the Step Out button or, while holding the Shift key, press the F11 key.

If we need to jump over a certain place in the program and start debugging from a new line, then this can be done in two ways. The first way is to set a new breakpoint and click the "Continue Debugging" button or the F5 key. Then the program will immediately jump to the required line of code.

The second way: position the cursor on the desired one and click on the "Go to cursor" button, or while holding the Shift key, press the F10 key.

If working with the code you get lost in it and want to quickly return to the current debug line, then just click the "Current line" button

We have learned how to move through the code in debugging. Now, the most important thing is how to find out the values ​​of the variables? This will help us scoreboard.

There are several ways to open it.

First: using the main menu.

Second: using the "Debug Configuration" panel.

Third: using the keyboard shortcut Ctrl + Alt + W.

A board appeared at the bottom where we can enter any variables and see their values.

In addition to variables of primitive types, you have the opportunity to enter variables of object types into the expression, and see their composition of this variable (if you are not debugging the execution of the code in c).

You can also add functions (both your own and the global context) to the scoreboard to find out what they will return.

You can find out the value of a variable without using the scoreboard. It is enough to select this variable and click on the "Calculate expression" button (key combination Shift + F9).

Watch a visual work with debugging in this video.

Learn the basics of configuring in 1C and learn to program in 1C: Enterprise using my books:

An excellent guide to developing a managed 1C application, both for novice developers and experienced programmers.

1. Very accessible and understandable language of presentation
2. The book is sent by e-mail in PDF format. Can be opened on any device!
3. Understand the ideology of a 1C managed application
4. Learn how to develop a managed application;
5. Learn to develop controlled 1C forms;
6. You will be able to work with the main and necessary elements of the managed forms
7. Programming under the managed application will become clear

Promo code for a 15% discount - 48PVXHeYu

If this lesson helped you to solve any problem, you liked it or turned out to be useful, then you can support my project by transferring any amount:

you can pay manually:

Yandex.Money - 410012882996301
Web Money - R955262494655

Join my groups.

It is necessary to use debug mode in 1C when designing and testing typical and independently developed configurations of any complexity. This mechanism helps developers not only to eliminate the identified errors, but also to anticipate many bottlenecks before the system is put into operation. To use all the capabilities of this mode of the 1C: Enterprise 8.3 platform, you must not only enable it, but also know the purpose of its main tools.

Enabling debug mode on the 1C server

If you work in the client-server version, then you need to go through the procedure for enabling debugging on the server to use all the functions of the 1C debugger. It does not take much time and does not require extensive knowledge, but you still have to be careful, because the process will affect changing the registry on the server.

You can enable debugging in 1C using the following algorithm:

• Go to the 1C server and open the register through the "Run" function from the "Start" menu. You can also use the Windows and R keys on your keyboard at the same time. Enter the command to open the register - "regedit";

• In the window that opens in the tree on the left, follow the path: "HKEY_LOCAL_MACHINE", "SYSTEM", "ControlSet001", "services", "1C: Enterprise 8.3 Server Agent";

• Selecting the bottom item, on the right side we find the attribute named "ImagePath" and change it using the context menu. To enable debugging on the server, add the line "-debug" to the existing path;

• It remains only to restart the 1C server agent and you can use the debug mode on the server.

To start debugging through the client application, go to 1C in the configurator mode and select the desired mode in the "Debug" menu. Most modern configurations work in thin client mode, therefore, it is better to debug performance in this type of client. If your configuration uses different types of clients, then for added peace of mind, you can test the functionality in all modes. At the moment of starting the debug mode, 1C opens the "Enterprise" mode.

As soon as 1C is launched in debug mode, you will see an almost similar program window. The only difference will be at the bottom - 1C shows statistics on the number of calls on a gray background. But if you switch to the configurator at this point, you will notice that the top panel has changed. There are new buttons with which you will control the debug mode.

To get the most out of debugging server procedures, you need to know the main features of this mode, their purpose and how to use them. Of course, it is impossible to understand everything on a theoretical level, but when you get acquainted with the basics, then in practice it will be much easier for you. In addition, most of the features of debugging are rarely used, so a deep knowledge of this mechanism may come in handy only after a few years of work.

Among those capabilities of the "Enterprise" debug mode, which 1C developers use regularly, the following can be distinguished:

• Breakpoints;
• Step-by-step code debugging;
• View values;
• Call stack.

Debugging functions 1C

The main debugging feature is to start debugging and check how the code works when working in 1C Enterprise mode. To do this, 1C developers set a breakpoint on the algorithm line. To do this, select a line with the mouse and press the button with the image of a red circle. Alternatively, you can double-click on the bar to the left of the module text, or use the F9 hotkey.

Use the Debug menu to see the set breakpoints. There you can remove all points, disable them, add a new one and get acquainted with the "hot" keys. Also in this menu you can set a breakpoint with a condition (in the form of a blue circle). It is useful in situations where you need to check the code when a condition is met that you have to write when setting a point.

Another useful mechanism from this menu is "Stop by mistake", which allows you to stop only in unacceptable situations. After stopping, you are taken to the configurator and can use other debugging options. For example, move through lines of code using special keys described in the "Debug" menu, where more popular functions are displayed at the top. The difference between F10 and F11 is that in the first case, you will end up in nested functions and procedures.

Server-side debugging in 1C is also good because you can see the value of variables after executing each line of code. The simplest option is to simply hover the mouse cursor and 1C will display the value in a pop-up window. But in the platform, in the "Debug" menu, two more tools are built in:

• When called, a window opens in which you can drag the variables by selecting them by double-clicking them in the code. The window shows their value and type throughout the entire debugging - you can follow the change during the execution of the algorithm;

• A mechanism for situations when a developer wants to model what data he can get on the current run of the algorithm. Allows you to write any expressions and shows their meaning.

Sometimes developers need to know the sequence of calling procedures in an algorithm. To do this, they need to use the call stack mechanism from the Debug menu. When you call it, a window opens in which you can see from which procedure the one where the debug cursor is located.

It is important to know and apply all of these tools to conduct tests before transferring your improvements to the production base. The above set of mechanisms is more than enough for the successful productive work of a developer in 1C. But it is also important to keep an eye on new functionality, since debugging on a 1C 8.3 server may acquire new capabilities in a few years.

Greetings to all readers of the portal site, in this article we will talk about breakpoints in 1C, or rather about their incorrect operation in certain versions of the 1C platform.

At the end of May 2015, a new platform 1C 8.3.6.2014... When working with this platform, many programmers encountered problem situations. In particular, properly Breakpoints did not work in the configurator when debugging an application... As it turned out, problems were noticed when debugging external processes using the "Testing external printable" processing.

Let's first take a look at how the "Testing external printing plates" processing works. With the help of this processing, we indicated our external processing (external printing plate, for example) (1), and then opened the same printing plate in the configurator and set breakpoints, after which we launched the enterprise under debugging. By pressing the button (2) it was our external printable that was launched, and not the system generated by default in the tmp directory, as a result, a breakpoint was triggered in our processing opened in the configurator. Everything worked as expected. But that was before ... If we perform these actions in the 1C platform 8.3.6.2014, then breakpoints in external processing will not be triggered! As it turned out, this situation arose because platform 1C 8.3.6.2014 loaded external processing into RAM, while the younger versions of the platform saved it to a temporary file, which was located in the default 1C temporary files directory.

Solving the problem with breakpoints in external processing on the 1C platform 8.3.6.2014

Unfortunately, at the moment, it was not possible to solve the problem with breakpoints in external processing on the 1C platform 8.3.6.2014... The thing is that this version of the platform stores processing in RAM, and the debugger does not get there, since we cannot open processing in the configurator and set a breakpoint. Let's hope that specialists from 1C will make it possible to enter RAM with a debugger, or come up with alternative debugging methods.

8, there is a need (see below) for a significant revision of the debugging procedure. This is reflected in version 8.3.7.1759. Firstly, a universal interface was created for this procedure, and secondly, such a change ensures the further development of the program itself. After all, now you can work with debugging not only through the Configurator, but also using the Development Tools. Let's consider 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, controlled client and server applications using the TCP / IP protocol.

Currently, the use of such a protocol has begun to restrict the access of 1C: Enterprise to the Internet and caused inconveniences for the operation of mobile applications.

Therefore, for free access to infobases that may be outside the local grid, the flexible HTTP protocol has now been adopted.

New architecture

Previously, when performing configurator debugging, an employee had to connect to the infobase. This required giving him administrator rights.

In the new version, there is no need for a direct connection to the databases - you just need to have the same database as the client has. And you can download it from a file.

Mobile applications

Over the HTTP protocol, it is now possible to debug both server data and client data and applications.

Other changes

With the new version, changing the values ​​for local variables is available in the debug procedure - for this purpose, a new quick view window has been implemented.

The calculation mode has been changed to asynchronous, which allows you to continue working without waiting for the 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 has been introduced into the new 1C environment: Enterprise Development Tools.

How it looks now

After changing the program, the procedure follows the following scenario:

Now it involves more than just the debugger and objects, as it was before. An additional element has now been added to the chain - Server.

Not only has it been added - it serves as the main piece of information exchange between the debugger and items. And the exchange itself takes place through queued messages.

And since this exchange is carried out via the HTTP protocol, now it does not matter where exactly the data can be located.

Server calls are generated by the debugger and objects in the form of additional connection requests. If there are any, appropriate answers are sent to them.

Enabling debugging in different scenarios

For the application developer, there have been no changes. The significant difference is that the new mechanism needs to be turned on. After all, it is now disabled by default.

Consider what happens when the mode starts if we choose one of the two scenarios.

File script

At the beginning of the file variant, it is necessary to specify in the configurator settings the use of the new mechanism - "Debugging via the HTTP protocol".

Then the Configurator will automatically offer to use the local server. This condition must be accepted and the program must be restarted in the Configurator mode.

After that, the newly launched Configurator at the next session will save the new method we have chosen. But for the same information base. Therefore, when accessing another information base, it also needs to be turned on.

The enabled mechanism will now automatically launch the Debugger Server, which is a special dbgs.exe application. It is reflected in the Task Manager window.

The value of the ownerPID parameter will correspond to the identifier of the application that is associated with it.

When starting a debug session through the Configurator, the server connection will be made automatically. And connected objects will be reflected in it.

If the 1C program was activated without a new mechanism, then you will need to manually enable debugging on the 1C server. Only now you will need to specify the server address:

Go to Service - Options

It is located in the item settings:

We go Connection - Settings

When using a file script with several databases at the same time, you need to take into account an important nuance - each of the Configurators (with the enabled mechanism via HTTP) sends its Server:

Therefore, if several Configurators are open, then to connect the Client you need to specify the correct one.

Client-server script

Debugging on the 1C server according to the client-server scenario, as in the previous case, begins by starting the mode. This specifies the use of the new HTTP mechanism. This is done in this way:

ragent.exe -debug -http

When you start it, the debugger automatically starts after it.

The ownerPID parameter value 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 the local one as in the previous scenario). We agree and restart it.

In the future, everything will run like a file script. Only when you start the Server Base Configurator, the local debugger server will no longer be started.

We hope that our publication helped you figure out the problem of how to enable debugging on the 1C server.