This implements a way to not output the debug trace to disk until the user hits Alf + F12. The goal is to avoid too big trace files.
I had this problem, and solved it using an external mechanism. I wrote an app that sends a clientmessage, and wrote a handler for that client message.
The things I could do are change debugging flags, so effectively, i could turn trace on/off.
I could call functions, like WIN_WalkWindows and others, if i knew ahead of time what they were.
This lead me to another thought I think might be useful, adding a runtime interpreter, and using something my clientmessage, send snippets of code to be executed, much like running gdb, but not as invasive. the language could be anything that has a reasonable interpreter, something like C# :-) My goal is to have something that could look for events, when they happen, rather than trying to wade through dbg_printf statements. something that is potentially interactive...ie. when event A happens, the trigger action B to happen....
another thought is that i could dynamically load/unload a dll, that would load, do its diagnostics during init, and then unload when done.
I think it would be much better to do that with a small external program that you pipe the debug output into. This way you can have much more flexibility
the problem is that you cant change things on the fly...what you want is to have the debugging options you want, selected when you want them, and then turned off. my clientmessage tool does this. i can start with no debugging, then have it start with what i want, and then, i can turn it off again...
My goal is to use what is already there, but to make it much more dynamic. Then rather than doing post mortem examination, we can do it live. My thought is why can't we use the builtin debugger, asyncronously, driven by an external application that has some logic that can be used in real time.