OK, I found a couple more small inconsistencies, a variable that's not being used and added some frivolity for fun. The upload below is good and complete (with the exception of a counter starting at 2 instead of 1 that doesn't really matter). So at some point I will post a final but in the interest of not annoying everyone with continual uploads and fixes I'm going to spend some time actually going through it all one final time and making sure it's as polished as I can make it (without turning it into a full-on app) and will upload again at some point soon.
But what's below works fine as it is. The final version will just be a little bit more refined.
=====================
CallStack Demo3.zip
=====================
OK, I think I'm done working on this demo. I've changed it so that it doesn't create an endless list of files. You can can specify a maximum number of callstack logs as well as number of callstacks per log.
So if you want you can specify a max of 1,000 logs with one call per log or one log with 10000 stacks in it or whatever you want as long as you stay within the limits of a long integer data type and system limitations (maximum file size your OS allows, disk space, memory, etc.).
A little more polishing was done.
If you have MZTools or something like it you can create a macro that automatically inserts the callstack stuff into any procedure with the correct information.
I really like MZTools.
=====================
When it's userful:
Normally it isn't. If you're having a problem during development then you use the built-in callstack viewer in the IDE.
It's useful when your app is crashing the IDE or when the compiled app is crashing for reasons unknown.
What it does:
It counts every call to every procedure that adds to the call stack. When the program exits (only if it's enabled at exit) it provides a list of every procedure called, how many times it was called and the deepest call stack.
Every single call is logged to file. The file is opened and when the max number of entries (specified in the cCallStack Initialize Sub) is reached it closes the file and opens a new one.
So if you look at one of the callstack files you see that the stack increases one call at a time.
When the program exits on purpose the current active callstack file is closed.
if the program crashes when a file is open then we count on Windows to close the file and hopefully you'll be able to look at the last callstack in the last file and see the stack that led up to the crash.
In my real app, all the totals are put into an application log file. In the demo it's put into the immediate window.
If you do too much with the demo then all the stats will be scrolled off the top of the immediate window so you just want to type a little bit, click a few things and then exit.
You could also just write that to the Windows Clipboard then paste it into a text document instead.
You will find that in the CloseLogFile Function in the ErrorHandler bas module.
Where this really shines is that if you're in the IDE and something is going on and you set a breakpoint AND you have some kind of API thing going on, such as changing the color of a toolbar or SSTab or whatever, the program might crash and bring down the entire IDE even if the API call wasn't the problem.
This allows you to keep running and figure out what's going on without hitting CTRL+ Break to pause program execution which can sometimes kill everything for reasons other than whatever actual problem you're trying to sort out.
I'd appreciate any feedback you can give me.
=====================
But what's below works fine as it is. The final version will just be a little bit more refined.
=====================
CallStack Demo3.zip
=====================
OK, I think I'm done working on this demo. I've changed it so that it doesn't create an endless list of files. You can can specify a maximum number of callstack logs as well as number of callstacks per log.
So if you want you can specify a max of 1,000 logs with one call per log or one log with 10000 stacks in it or whatever you want as long as you stay within the limits of a long integer data type and system limitations (maximum file size your OS allows, disk space, memory, etc.).
A little more polishing was done.
If you have MZTools or something like it you can create a macro that automatically inserts the callstack stuff into any procedure with the correct information.
I really like MZTools.
=====================
When it's userful:
Normally it isn't. If you're having a problem during development then you use the built-in callstack viewer in the IDE.
It's useful when your app is crashing the IDE or when the compiled app is crashing for reasons unknown.
What it does:
It counts every call to every procedure that adds to the call stack. When the program exits (only if it's enabled at exit) it provides a list of every procedure called, how many times it was called and the deepest call stack.
Every single call is logged to file. The file is opened and when the max number of entries (specified in the cCallStack Initialize Sub) is reached it closes the file and opens a new one.
So if you look at one of the callstack files you see that the stack increases one call at a time.
When the program exits on purpose the current active callstack file is closed.
if the program crashes when a file is open then we count on Windows to close the file and hopefully you'll be able to look at the last callstack in the last file and see the stack that led up to the crash.
In my real app, all the totals are put into an application log file. In the demo it's put into the immediate window.
If you do too much with the demo then all the stats will be scrolled off the top of the immediate window so you just want to type a little bit, click a few things and then exit.
You could also just write that to the Windows Clipboard then paste it into a text document instead.
You will find that in the CloseLogFile Function in the ErrorHandler bas module.
Where this really shines is that if you're in the IDE and something is going on and you set a breakpoint AND you have some kind of API thing going on, such as changing the color of a toolbar or SSTab or whatever, the program might crash and bring down the entire IDE even if the API call wasn't the problem.
This allows you to keep running and figure out what's going on without hitting CTRL+ Break to pause program execution which can sometimes kill everything for reasons other than whatever actual problem you're trying to sort out.
I'd appreciate any feedback you can give me.
=====================