views:

228

answers:

3

I'm using Delphi 2010 and I'm wondering if there's a way to trace through code which is in the project without tracing through calls to included VCLs.

For example - you put in a breakpoint and then use Shift+F7 to trace through line-by-line. Now you run into a call to some lengthy procedure in a VCL - in my case it's often a Measurement Studio or other component that draws the doodads for a bunch of I/O, OPC, or other bits. At any rate, what happens is that the debugger hops out of the active source file, opens the component source, and traces through that line by line. Often this is hundreds or thousands of lines of code I don't care about - I just want to have it execute and return to the next source line in MY project.

Obviously you can do this by setting breakpoints around every instance of an external call, but often there are too many to make this practical - I'd be spending an hour setting a hundred breakpoints every time I wanted to step through a section of code.

Is there a setting or a tool somewhere that can do this? Allow one to trace through code within the project while silently executing code which is external to the project?

Thanks in advance, Stack Overflow!

+9  A: 

The debugger won't step through units that don't have debug information, so the goal is to make the compiler omit debug information from the units you're not interested in.

Put your library units in a separate library project. That gives you the ability to have separate compilation settings for those units without affecting your project. Compile the library without debugging information enabled. Then remove those library units from your project. You can continue using them, but they won't belong to your project anymore.

An important aspect here is that the DCUs should reside in a separate directory from the source code. If the compiler finds DCUs and it happens to see the source code in the same folder, then it's liable to recompile that code when you really don't want it to. Set your projects' "DCU output folder" to something other than the default.

To really do it right, you can do what the VCL does and compile two different versions of your libraries. Compile one with debug information, and one without, and put the compiled files in different directories. Add the directory with the debug versions to your Delphi configuration; there should already be a folder listed there that contains the Delphi-provided debug DCUs.

When you set up two different versions, you allow yourself to choose whether you want to step into the library code. Simply toggle the "use debug DCUs" option in your project settings. Delphi will automatically add and remove the debug-version folder from the search path when you toggle that setting.


Note that even though you'll have a separate library project for your library units, you don't need to link to or distribute the DLL or package that that project generates. You can continue using the DCU files directly in your EXE project. You're only setting up the separate project so that you can select different compilation settings for those units. Add the library project's DCU output folder to your EXE project's search path, and you can continue using the units directly without any need to distribute the library project's DLL or package.

The IDE may try to add new directories to the search path automatically. Don't stand for that. If there's a source directory there that the IDE added for you and you don't want it there, feel free to remove it. The IDE is just trying to be helpful, but it doesn't know about your plan to have separate source and compiled folders.

Rob Kennedy
Thanks, Rob - that's very helpful. At present the libraries aren't included in the project, they're simply BPLs that have been added directly to Delphi via "Components->Install Packages..." I checked my bin/packages directory, however, and found that the source files are indeed in subfolders there along with the DCUs. I'll try what you suggest and see if I can't get it behaving sensibly. Thanks kindly - I wish I could buy you a beer!
Justin
I just noticed my ambiguous use of "included" in the original post - I suppose I should have said that these were only included to the extent that they were referenced in the "Uses" sections of my units and not that I physically stuck the sources in my project. Just the same, I think it was indeed the stray sources in the bin folder that Delphi was digging out of the underworld to trace through. Gotta keep this one on a short leash, eh?
Justin
+3  A: 

Another method is to use the debug information and Local symbol information compiler directives - add {$D-$L-} to the start of each unit.

This will ALWAYS suppress the generation of debug information for that unit. If you do need to trace into the code, comment out the directives.

Gerry
Not a bad suggestion - I've done this for files in my own projects, but in this case with component libraries it can be a lot of source files to go in and edit, especially when the calls should be going to already compiled units installed in the IDE. I think Rob hit it on the head with the stray sources in bed with my DCUs.
Justin
@Justin: Maybe you can just do it to the few that you find yourself entering 98% of the time.
lkessler
@Justin, @lkessler - this is what I tend to do with the "98%" myself, but I have only used a small number of 3rd party components recently
Gerry
I could, but forcing it to use the compiled units is altogether more elegant and to the point, I think. I've got lots of extra libs with lots of micro sources, all of which I use extensively. It's for industrial control systems, so the structures tend to be a lot more modular than for desktop apps, I think.
Justin
+2  A: 

Just to complete your options: If your libraries for some reason must be compiled with debug information (I usually use everything with debug info, including the VCL and RTL.) and you accidentally trace into a method you are not interested in, you can use Shift+F8 to run until the method returns to your code.

dummzeuch