Hide VCL procedures in Call Stack in Debugger?

[Tom F 80]

Is it possible to suppress the display of lines in the debugger's Call Stack that are not in my source?  For example: VCL, Kernel, etc. 

I don't want to see the highlighted lines.

Edited October 3, 2019 by Tom F

[Guest]

I do not know. But if you compile with "Debug DCUs" those entries will make more sense.

I sometimes Ctrl+C the call stack and put it up in BeyondCompare or EditPad to be able to analyse. Could be a workaround for the time being, until someone more knowledgeable answers.

On another note; IMHO to suppress the inner workings of ones own code is a bit counter-productive education-wise. But that is preference.

[dummzeuch 1386]

I think that window uses TVirtualTreeview which would make it nearly impossible to read it's content and modify it with a plugin, unless there is an OTAPI interface for it.

 

But this is guesswork, I haven't really checked either.

[Dinar 22]

Perhaps the answer to this question on stackoverflow or the information from the article "Selective Debugging" will help you

[Uwe Raabe 1877]

Selective Debugging allows to select the debug DCUs on a per unit basis. This doesn't affect the content of the call stack.

 

Honestly, I doubt that removing this information from the call stack is of any benefit at all. In fact it would camouflage the actual program flow rendering the call stack next to useless.

[Tom F 80]

6 hours ago, Uwe Raabe said:

I doubt that removing this information from the call stack is of any benefit at all.

 

Hi, Uwe,

Actually, I'd find it quite useful to remove VCL entries from the display of the call stack in the debugger.

If the call stack is "cluttered" with a lot of VCL entries, it makes visually scanning it more work and may introduce the need to scroll the list.

Although there are times that seeing how the VCL is being used might be helpful, most of the time many of us are only interested in our code, not the VCL.

Anyway, from the responses I got here, it seems like hiding the VCL in the call stack in the debugger isn't something that can be easily done, if done at all.

Thanks for your comment.

Tom

[Guest]

5 hours ago, Tom F said:

most of the time many of us are only interested in our code, not the VCL

So if your code is ok, and you hve stumbled upon a VCL (or RTL, for that matter) bug, then you will probably waste loads of time trying to fix your code.

Once again; a thorough understanding of the libraries, environment, compiler and processor is key to produce good code. Anything that obscures these utterly important "atoms" is regressive.

Sorry, i should be quiet.

[Tom F 80]

Hi, Dany,

No, please don't keep quiet!  I appreciate your insight. And it's interesting to me how in your and others' experience, seeing the call stack in the debugger into the RTL is important.  

My experience is different from yours.  I've managed over 1.5 million lines of code over more than a decade. And I've never once encountered an RTL bug.  Of course, years and LOC don't prove anything. I mean, maybe the code is trivial and braindead and doesn't do anything that might encounter a bug.

Maybe I'd be more informed and a better programmer if I traced into the RTL more often and studied its code.  Maybe because I don't do that, I'm really not using the RTL and VCL as effectively as I might.

There's no way to know, but I'd think that (in spite of lots of complaints we see online) the majority of Delphi users have never encountered an RTL bug. At least I hope that's true! 🙂 But, maybe I'm wrong.

Anyway. I'm not intending to be combative.   I just know that my preference would be not to see the RTL in the debugger call stack.   It sounds like that's not going to happen, so I'll just have to scroll the stack view in the debugger more often and learn to ignore entries that AFAIK I don't need to see.

Thanks again for sharing your experience.  I'd be interested in hearing what others have to say about this. But, not in an adversarial way, but because I genuinely wonder how often the RTL stack is important in day to day use.  

 

Edited October 15, 2019 by Tom F