using global variables for app instance referencing (1 Viewer)

[neuroman9999]

how prevalent is global var usage for any given purpose in this program? I use them all the time, and I always have strictly for the purpose of lessening repetitive routines that use the same type of table data. and is there any instance while an access app is open that a global var's memory would be destroyed, outside of quitting the app or setting it to nothing, literally?

for instance, is there anything wrong with this code in the eyes of the pros?

behind form:

login_form_button_click()
user = getComputerName()

in global var module:

Public Declare Function getComputerName Lib "user32" () As Long
'DLL code here

 

[The_Doc_Man]

Since this is the VBA thread, I'll answer in that context.

is there any instance while an access app is open that a global var's memory would be destroyed, outside of quitting the app or setting it to nothing, literally?

Yes. If you have an unhandled exception / error, you might get the dreaded "Unhandled exception" notice that gives you the options to Continue (which is often not available), Reset, or Debug. If you do the Reset option, all globals are re-initialized to "", 0, nothing, or null as appropriate.

 

[neuroman9999]

so, are you referring to the breakage that happens when you have a large routine, you have ""break on all errors"" set, the code breaks, then you start writing new lines of code in the VBE while it is broken and you see the yellow offending line, and while doing that you see a message that says:

performing this action will reset your project. contine?

????

kind of like what one would see in a large routine that thew this kind of error under the above scenario I just described?

 

[The_Doc_Man]

What you showed in the bottom panel with error 91 is the nuclear option to which I referred except it says END instead of RESET. If you take "END" you reset everything. And note that "CONTINUE" is grayed out so you can't do that. Sometimes you CAN continue. That example wasn't one of those times. Most but not all errors that produce that particular type of dialog box will not allow CONTINUE. I.e. being allowed to CONTINUE is very rare.

This pop-up modal box occurs because Access doesn't DARE allow Windows to invoke its "Last Chance Handler." If Access didn't handle the error with its own "internal Last Chance" handler, then Windows would force Access to abort ("crash"). That "nuclear" option keeps Access in control but at the expense of killing and resetting nearly everything else that Access was doing. All sorts of bad things happen with the END option. I understand that TempVars are NOT wiped out but a lot of other things are. I must admit I have not researched everything that gets killed by the nuclear option.

You do not often see much discussion regarding the "Last Chance" handler, but here is an explicit reference to it.

Exception Handling Functions for Debugging - Win32 apps

When an exception occurs in a process that is being debugged, the system notifies the debugger by passing the exception to it. This is known as first-chance notification. The system then suspends all threads in the process being debugged.

docs.microsoft.com

 

[neuroman9999]

all good stuff Richard! your words will come in handy in the future, especially when I work with someone via teamviewer who is not regarding what their needs are. I have done this a few times, whereby I have them test the work that they requested of me, specifically because they were unclear about what they wanted when I initially talked to them, and thus it left me in a guessing game. When this happened, sometimes what I would do would be to watch them literally break the app, and then add "fix it" code on the fly after clarifying their needs based on what they were doing while I was watching. that is why I asked this to begin with. I have run into a situation before where variables were being emptied and it was causing errors that I was unaware about, and that caused the testing process and remote session to be a living hell. but now I know what to do, thanks to you.

on a side note, I find it quite funny that you can use the word nuclear here, in any context, and not get reported for being a wanna-be hate speech invoker by some crazy politico, but yet I can't make a joke and call you "g o o f ball" without being censored, or can't make a joke on LinkedIn about rich people causing criminals who are ignorant and telling them that no police force on Earth can stop 5 million people storming their home and wanting to "b u r n it down", without LinkedIn sending me an email, taking down my comment and telling me I violated the terms of service.

 

[The_Doc_Man]

The distinction is that I wasn't using "nuclear" in reference to people but rather to a program. You have used that name to describe people in what you refer to as "having fun." Having fun at the expense of another member is the action that gets you in trouble. My use of the word "nuclear" does not constitute a threat. Besides, I left my nuclear weapons in my other pants and they are at the dry cleaners.

I have run into a situation before where variables were being emptied and it was causing errors that I was unaware about,

I'm guessing, of course, but that little four-option box or some other kind of inadequate error handling was involved. I will add a small amount of advice if I may. When you want to trap an error that you suspect might happen, trap it in the same routine where you expect it. The reason is that an untrapped error diddles with your program stack.

In that article I referenced, it says "Access searches for a handler" but that was a summary level statement, necessary because that was supposed to be a short article. Here is what REALLY is going on.

When you write VBA code, Access is your MAIN program. Your event routines are subroutines called (indirectly) by Access when the given event occurs. Event routines can also call any subroutines or functions you have written. Each time you or Access calls a subroutine, the current machine context is saved on the user's program stack to create a new execution context. When you return from a subroutine, this saved context is what is used to return to the subroutine's caller. With me so far?

If you are in a subroutine and declare an exit handler, there is a place in your current context (called a Frame in some circles) that remembers the address you named as the handler within this routine. (The On Error GoTo X statement does that.) Suppose you then call another subroutine. In that new subroutine, you can establish another handler. Let's say you DID that. When you exit this 2nd level subroutine, which handler is active? The one in the context to which you returned, because the context that holds the most recent handler was discarded when you did the RETURN or END SUB instruction. So the previous stack context is restored - and that includes the handler. The 2nd level context is discarded.

Where am I going with this? Let's say you have an event routine that calls a subroutine that calls another subroutine. So that is three layers deep. You can set this up and verify it from the VBA screen by using View>> Call Stack. Now suppose you take a fatal error in that 3rd-level routine. So Windows handles the error by looking in the current call context to find your handler. If you don't have one in this level, Windows does what is called a Stack Unwind as it discards your current context and then restores the caller's context. This error process repeats again because the error is now raised again (re-signaled) once the Unwind is complete. Suppose you don't have something set up in the level 2 routine. So another layer of the stack gets unwound and another caller's context is restored, this time the 1st level (event) routine. Let's say IT fails to find a handler.

This process can only do two more stack unwinds. The first one returns to Access itself, because it was the caller of your event routine. As noted, Access has a "last chance Access handler" so that stops the process, the error is signaled, and Access retains control. In fact, that screen shot you showed us is probably an example of exactly this situation.

But let's do a hypothetical follow-up. SUPPOSE for the sake of argument that Access didn't have a last-chance handler? Well, what happens then is easy. You see, every process under Windows is actually a subroutine of the windows Process Scheduler. So if ACCESS failed to manage the error, Windows ALSO has a last-chance handler residing in association with the system Process Scheduler, the thing that launches tasks.

The reason Windows handles this is mostly because Access merely calls the Windows debug support routines that are common to any Windows executable image. But because a Stack Unwind is a distinct possibility, Windows usually takes over momentarily.

 

[neuroman9999]

The distinction is that I wasn't using "nuclear" in reference to people but rather to a program. You have used that name to describe people in what you refer to as "having fun." Having fun at the expense of another member is the action that gets you in trouble. My use of the word "nuclear" does not constitute a threat. Besides, I left my nuclear weapons in my other pants and they are at the dry cleaners.


I'm guessing, of course, but that little four-option box or some other kind of inadequate error handling was involved. I will add a small amount of advice if I may. When you want to trap an error that you suspect might happen, trap it in the same routine where you expect it. The reason is that an untrapped error diddles with your program stack.

In that article I referenced, it says "Access searches for a handler" but that was a summary level statement, necessary because that was supposed to be a short article. Here is what REALLY is going on.

When you write VBA code, Access is your MAIN program. Your event routines are subroutines called (indirectly) by Access when the given event occurs. Event routines can also call any subroutines or functions you have written. Each time you or Access calls a subroutine, the current machine context is saved on the user's program stack to create a new execution context. When you return from a subroutine, this saved context is what is used to return to the subroutine's caller. With me so far?

If you are in a subroutine and declare an exit handler, there is a place in your current context (called a Frame in some circles) that remembers the address you named as the handler within this routine. (The On Error GoTo X statement does that.) Suppose you then call another subroutine. In that new subroutine, you can establish another handler. Let's say you DID that. When you exit this 2nd level subroutine, which handler is active? The one in the context to which you returned, because the context that holds the most recent handler was discarded when you did the RETURN or END SUB instruction. So the previous stack context is restored - and that includes the handler. The 2nd level context is discarded.

Where am I going with this? Let's say you have an event routine that calls a subroutine that calls another subroutine. So that is three layers deep. You can set this up and verify it from the VBA screen by using View>> Call Stack. Now suppose you take a fatal error in that 3rd-level routine. So Windows handles the error by looking in the current call context to find your handler. If you don't have one in this level, Windows does what is called a Stack Unwind as it discards your current context and then restores the caller's context. This error process repeats again because the error is now raised again (re-signaled) once the Unwind is complete. Suppose you don't have something set up in the level 2 routine. So another layer of the stack gets unwound and another caller's context is restored, this time the 1st level (event) routine. Let's say IT fails to find a handler.

This process can only do two more stack unwinds. The first one returns to Access itself, because it was the caller of your event routine. As noted, Access has a "last chance Access handler" so that stops the process, the error is signaled, and Access retains control. In fact, that screen shot you showed us is probably an example of exactly this situation.

But let's do a hypothetical follow-up. SUPPOSE for the sake of argument that Access didn't have a last-chance handler? Well, what happens then is easy. You see, every process under Windows is actually a subroutine of the windows Process Scheduler. So if ACCESS failed to manage the error, Windows ALSO has a last-chance handler residing in association with the system Process Scheduler, the thing that launches tasks.

The reason Windows handles this is mostly because Access merely calls the Windows debug support routines that are common to any Windows executable image. But because a Stack Unwind is a distinct possibility, Windows usually takes over momentarily.

yes I followed all of that. but it's a lot to take in. I'm not an expert in stack leveling or the unwinding process, but I am now! thanks to you for providing extremely valuable info that will be written down and referred to later if need be.