Tips & Tricks: how to debug large applications

by Giuseppe Lanzi on 01/22/2015

As many of you already know, Instant Developer is equipped with two different debug modules: the step-by-step debug, as you’d find in traditional environments, and the debug at run-time, which makes it possible to retrace and analyze the entire history of the application session.

The default debug type is the run-time debug, and it’s enabled automatically when you compile the project the first time. It recognizes and blocks both cycle loops and stack loops, keeps track of the status of the variables and the results of the functions, and provides information about the number of calls and about where the execution time is used. It is a very powerful tool, basically, but in some cases it can require a little configuration.

To keep track of all this information, the application must of course keep it all in memory. The more complex the application becomes, the larger the amount of memory the module occupies, as does opening the debug itself. In some cases, we can have procedures that are very difficult to debug because of their recursiveness and the number of other procedures that will be called. Sometimes, the amount of memory required is simply too large, or the number of objects to be displayed in the debug window is too high for the browser, which takes minutes to display the result.

This is exactly why today I want to talk about those two buttons to the left of the name of each procedure involved in the open request in the debug. The ones you see in the image above.

The button on the left is used to disable/enable the debug for the corresponding procedure, so you can avoid using system memory for all the methods that you already know work properly.

The button on the right will hide/show the corresponding procedure in the debug window, allowing you to view only those methods that need to be investigated and hide the others.

The user’s choice is saved in the application output folder, in the dtt.ini file that contains the GUIDs for the procedures and the corresponding configuration. Upon each subsequent recompilation, the configuration is preserved and reused by the application at run-time.

You can try it by downloading this example project. If you try clicking on the Procedure 1 command and open the debug, you won’t see calls to Procedure 2. This happens because in the project zip, I have also included the output folder that I configured myself. Now try re-enabling both the functions for the second procedure and repeat everything: you’ll see that both the debug opening time and its size are noticeably different.

More information on the debug module is available in Chapter 12 of the User’s Guide.

Enjoy. :).

Leave a Comment

Previous post:

Next post: