Losing global variable in a report

[ChrisO]

Stoss.

At this stage we have virtually no code that you are using.

Please post a cutdown demo of your database or try to simulate it in a new database and post it.
Try to keep it to the absolute minimum to demonstrate your problem.

Access 2003 please.

Chris.

 

[Stoss]

At this point, it looks like there is a difference when I close out of Access through the "X" or "File -- Exit" vs. a self made Exit button.

The code for the exit buttons are:
docmd.quit

I have tried application.quit acSaveAll but no luck

So, I am now wondering what the "X" button does that is different than the DoCmd.quit or Application.quit

-Stoss

 

[ChrisO]

Stoss, you are correct.

From Access 2003 help: -
“The Quit method has the same effect as clicking Exit on the File menu.”
RUBISH!

-------------

The: -
Application.Quit
is clearing the Global variable but the code is running on even to open the Report.

Small demo attached.

Chris.

 

[Stoss]

Rubish is right!!!!!!!!!

Anything I can do except delete all button exits and force the users to use the X or file - exit?

 

[ChrisO]

Well, first of all I would like to thank you for showing me this behaviour of the Quit command.
It is not something I have seen in around 8 years on the net, so it’s something learned.


I would like to clarify what exactly you are trying to do.
It seems, from the code so far, that you are trying to print a Report on database exit.
As we have seen that can be fraught with danger, not to mention (but I will) that we can not control how Access closes.
(Big finger push big button, lack of electrons…that sort of thing.)

However, one of the things you could try is to open the Report in Dialog mode before hitting the Quit line of code.
In Dialog mode the code should terminate on the Report open line till the Report is closed.
When the Report is closed the Quit should take effect.

If none of the above is correct or works we may just have to invent some way to do it.

Chris.

 

[Stoss]

I am so glad my pain and suffering could educate you

I don't think I can do dialog mode because sometime these reports are run from a Outputto call and sometimes it is called from an open form call.

 

[DCrake]

I have a demo in the Sample Databases that discusses the use of Public and Global variables. click on the link it may help you.

 

[Stoss]

ChrisO,

Just wanted to let you know I found a workaround (this really only applies to me in my situation though). In conjunction with all what I was doing, I also created a custom menu. In this menu I have an exit button. Here is the part you will like...instead of writing my own code to exit for it, I used a predefined Exit from Access menus. Because of this, it seems to work now. I.E. just like if I were to hit the X or File - Exit. For me in this case, this works because I was going to get rid of all button closes in my program anyway.

Still, I am a little upset that closes the MS way works and doing a docmd.quit doesn't.

Anyway, thanks to all that helped me with this, you all had a huge impact on me solving this issue (using solving loosely there).

-Stoss

 

[ChrisO]

Stoss.

Glad you found something that works in your situation.
I haven’t tested it but I suspect storing the value in a Table would have also worked.

Thanks also for not jumping to a quick workaround just to get the thing fixed. Too many times the real reason for a workaround gets overlooked and instead simply gets replaced by a quick fix. Even though, in the end, you used a workaround we all should now know why it was necessary. Application.Quit clears Global variables but the code still continues to run, with those cleared variables, even to the point of opening a Report after the Quit command.

So I guess that is the lesson learned. We should not jump to a quick fix because all we get is a quick fix but we do not learn why it was needed.

Now we do…

--------

David.

I think some of the code in that link is in error: -

Sub Test()

    dtmDateUpper = Empty
    MsgBox IIf(IsEmpty(dtmDateUpper), Date, dtmDateUpper)  [color=green]'  < 12:00:00 AM[/color]

End Sub

You may like to check that though.


Chris.

 

[The_Doc_Man]

Interesting...

The "predefined exit" using the form's control wizards will build a button event routine that has a trap handler local to that routine - which means that the trap will be handled within scope.

Just for S&G, take one of your roll-your-own exit routines. Add a trap handler local to that routine. Try it instead of your wizard-built exit routine. (Of course, that would be if time permits...) I'd be interested in seeing if that works.

 

[Galaxiom]

What an interesting thread. I am fascinated to see the difference between Application.Quit or DoCmd.Quit and the Windows Close Window button.

However I was wonding which path the Exit Access button (Access 2007) and the Exit menu command (earlier versions) follow.

 

[ChrisO]

Application.Quit seems to have an implied End involved, which clears variables, but does not end execution.

Code execution continues the shutdown process and in doing so calls the Form Close event.
In this case the Form Close event opens a Report but by that time the Global variable has been cleared, so it’s now a ZLS.

The Windows Close Window button does not seem to use the Quit method and does not appear to have the implied End statement. Under this circumstance variables are not cleared but the Form Close event is still called. The Form Close event opens the Report and the variable still has its value.

I have to assume that once the code in the Report stops running Access shuts down. At that point Access may or may not clear all variables, I don’t know.

So it seems that the shutdown sequence is basically the same in both cases except for the implied End, which clears variables, when using the Quit method.

I don’t know if A2007 does it the same way but the demo in post #23 could be converted and tested.

Chris.

 

[Stoss]

Doc Man,

I would love to but I think that this is a little out of my league. I do ok with coding but I am no expert by any means.

Well, are you talking about doing a "On Error Goto ErrHandler" type thing. That I am familiar with but I don't know if that is the same thing as "trap handler"

 

[Simon_MT]

frogive me for intruding, but i read somewhere on this forum not to use Global Variables. At the top of th thread, it was mentioned that a default form was used. I have had issues with multiple locations and I got around this but creating a Table and putting the 'global variables on this form. This Form always stayed open and was the only quick way of quitting the application. Admittedly, closing the Default Form the whole application fell apart, but tough, it was never meant to be closed until you wanted to quit the application. So I would tend to the location you require on the Default From rather than using a global variable.

Simon

 

[The_Doc_Man]

Well, are you talking about doing a "On Error Goto ErrHandler" type thing. That I am familiar with but I don't know if that is the same thing as "trap handler"

Exactly the same.

A trap is like a device driver's interrupt handler, but in this case, the "interrupt" is generated by software inside the Access run-time environment (RTE). Usually, by the error-checking elements of the RTE. When there is an error, the RTE intercepts it and "signals" a trap. The RTE then looks at the current context (i.e., what subroutine you are in) to see if an "On Error Then Goto xxxx" is in effect. If so, xxxx is going to get control and have the chance to look at Err.Number and Err.Description to see what went wrong.

My earlier discussion about "unwinding" the call stack is because if you don't have a trap handler, the current context cannot handle the trap. That means the system has to "blow off" the context of that routine and look for a trap handler in the caller of the original routine. And if that fails, the caller of the caller and so on until the entire stack is blown off looking for a trap handler. I believe that for VBA, since you cannot write a MAIN routine like you would with "regular" Visual Basic, your code will always be called by the RTE. So if your code has no trap handler but encounters a trap, the RTE takes the trap for you - but aborts everything you've been running.

As to the differences between Application.Quit and DoCmd.Quit, I think it would be important to determine which, if any, events actually fire. After doing a Google search, I see that there is a third player depending on the version of Access you are running - Access.Quit. There is also a "Quit" option in Macros. I wonder which one of the choices that one maps to if you convert it.

Some symptoms reported are that sometimes Access stays open even though the .MDB file closes IIRC, Application.Quit is the new kid on the block because the application object wasn't separately visible in older versions of Access. I've seen some Ac2007 issues that seem to indicate that I've got this problem too, but just never noticed it unless I happened to have Access open on two databases at once as separate windows. (I.e. not as an FE/BE split case.)

I can't research this right now as I have some other stuff I need to do, but I'll put this on a back burner and see what I can find.

 

[ChrisO]

Error handling does nothing because, in this case, there is no error.

Chris.