Call Stack, who knew??

[NauticalGent]

All the time I have wasted tracing through code when the ultimate short-cut was right there in front of me...

 

[plog]

How about a link or further explanation for those who follow and are in a similar situation?

 

[jdraw]

Lots of info if you google ms access vba callstack

 

[isladogs]

Hi
I've never used the call stack so would also be interested in knowing more.

I do know that UA member JonSmith has done a lot of work using this feature and has on several occasions written lengthy posts proclaiming its virtues. May be worth making contact with him

 

[theDBguy]

Here's one thread at UA discussing the subject. Cheers!

 

[NauticalGent]

Apologies for the delay, for some reason my computer at work does not like AWF. Frustrating...

In a nutshell, it makes debugging much, much easier - especially if your code calls Subs and Functions that are not in the current class module you are using.

When I first started using VBA, the vast majority of my code was confined to the form or report I was working on at the time. But as my skills improved and learned how to take advantage of my own UDF’s (thanks to the members of this Forum) it made debugging a bit of a challenge.

Using the Call Stack, I am able to trace back through the code via the Call Stack window. It places the current Sub I am in on the top. By clicking the other Subs in the window, it takes me to the point in the previous Subs where the other Subs were called. A real stream-lined process. Had I known about this feature before, it would have saved me hours of debugging.

 

[isladogs]

Thanks for posting the link DBG. That was the thread I was thinking of.
Despite JonSmith's very detailed code, I have to admit that I never got around to following it up as my own error handling routines have always been more than good enough for both my needs and my clients.

NG: Any chance of a simple example db that demonstrates its value?

 

[theDBguy]

Thanks for posting the link DBG. That was the thread I was thinking of.
Despite JonSmith's very detailed code, I have to admit that I never got around to following it up as my own error handling routines have always been more than good enough for both my needs and my clients.

NG: Any chance of a simple example db that demonstrates its value?

Hi Colin. Based on NG's description from his last post, I get the impression he's merely talking about hitting Ctrl+L while in debug mode.

 

[isladogs]

I introduced comprehensive error handling in every routine in my very large schools databases (FE approx 150MB). I did so because I couldn't rely on my clients to pass on detailed & accurate error information and so I couldn't fix issues unless I could replicate them

My error logging routine records all the details of each error - error number/description, exact location where it occurs, who was affected, workstation info, screen resolution, Access version & bitness, OS & bitness, app version etc ...
All of that info is then sent 'silently' by email to me (by agreement with the clients) without the user needing to do anything

The process took a very long time to setup (and I often felt like giving up!) & for the first few weeks after implementation I got a lot of automated emails. However there were relatively few errors involved (repeatedly) and allowed me to fix the bugs quickly
After a couple of months almost all the errors were fixed & I haven't received an error logging email for well over a year. I call that success!

Since then I now build in this code as I develop many of my new apps

 

[isladogs]

The last error logging email I received was from someone who had downloaded the DEMO version of an app from my website. That surprised me. I emailed back but got no reply

Anyway the point I was really making was that I haven't seen any benefit in using call stack as I have my own system. But I'd be happy to be persuaded of its merits. As previously mentioned, Jon Smith at UA had some impressive code based on this.

 

[The_Doc_Man]

After doing a bit of research, I verified that you can use CTRL/L to display the call frame list on the stack. Which is no "duh" because that was mentioned in this thread. I also noted that there is general agreement in many external articles that without playing a "roll your own DLL" type of game, there is no programmatic way to actually see what is on the stack. I.e. the Access GUI can show you but you can't easily do a VBA-based examination. This is because among other things, the stack usage is not constant and you cannot see the hardware registers - including the user-mode stack pointer.

From one call to the next, the number of items pushed onto the stack is dependent on the local declarations in the subroutine. The amount of space available to the stack is fairly large, but it is hard to say exactly how much stack space you do have. Fortunately, unless you are writing some pretty ugly recursive code, you are unlikely to get a "stack overlaps heap" message - which is quite fatal if you get it.

In the worst code I ever wrote, I think the deepest I've ever seen the stack using the menu to "show call stack" was about a half-dozen layers deep counting the starting Event routine at the bottom of the stack and having several shared formatting routines and computational assistance routines in the stack frame list.

The ability to click on a particular frame so you can see it is a really great debugging tool. And it should be noted that if you do that (i.e. switch code windows to the point where a call occurred), that routine's locally-declared variables and any public variables from a general module still show you their values if you hover the mouse over them - even though the executing code is not in that context at the moment.

I have written some recursive code and I can report that using the "Show Call Frames" option to visit each frame lets you see the correct values for that frame even though the call is recursive and another instantiation of it is elsewhere in the same call frame list.

 

[NauticalGent]

Hi Colin. Based on NG's description from his last post, I get the impression he's merely talking about hitting Ctrl+L while in debug mode.

Exactly. Really cuts down on my Debug time becuase it lets me “walk backwards” while I am trouble-shooting”. My coding skills are not what the should be so what most of you get done right the first time takes a few attempts for me! Getting better though, if I do say so myself...

The ability to click on a particular frame so you can see it is a really great debugging tool. And it should be noted that if you do that (i.e. switch code windows to the point where a call occurred), that routine's locally-declared variables and any public variables from a general module still show you their values if you hover the mouse over them - even though the executing code is not in that context at the moment.

Doc nails it. What I had to do with a #2 pencil and a notepad can now be done on the fly. I can even make my changes and re-run the code from that point - a real time saver.

Funny thing is, it has always been there an two of the books I have bought talk extensively on how to use it but it was too “busy” to take the time to read and understand it. Life is tough, tougher if you’re stupid...

 

[NauticalGent]

I found an article from Mike Wolfe that relates to this thread...excellent read!