New Event: 'On Access Application Window Close'.
This event must have a Cancel option also.
This would be an Application Level event (not a Form event).
Many developers have requested this over the years.
More often than not, you want to check some conditions before a user closes Access
Of course, there are various workarounds, but we should not have to bother with workarounds, as well as additiona workarounds to deal with potential issues when Access is closing.
Most all professional applications have this. For example (only), when you click the X to Close Quickbooks Pro, a prompt occurs asking "Are you sure you want to exit?"
Please make this happen :-)
Thanks for posting Joe. We’ll look into this when planning our future investments.
When prioritizing suggestions and ideas we take into consideration the number of votes they get – so please be sure to vote for things you want to see done sooner.
Any progress/update on this ?
Leigh Purvis commented
I'd also want throw into the ring for consideration (I don't think it's listed elsewhere) the addition of other events too.
Primarily, I'm thinking about form level events, such as a BeforeCurrent (or BeforeNav) or whatever you might want to call it. (In ADO it's referred to as WillMove event.)
Other application events such as Application.FormOpen and Application.FormClose (which passes the form object, name, or hwnd as an argument) would allow for quite a lot too. (Similar in concept to other Office application document events.)
Jonathan Baynes commented
Joe, thanks for referring me to this earlier suggestion from you. I have deleted my parallel suggestion requesting the same thing.
Adrian Bell (MVP) commented
Even if there isn't a module defined as standard for the Application. In Excel I've used code such as below to expose Application events :
Private WithEvents xlApp As Excel.Application
With this in a ThisWorkbook module the events for xlApp even appear in the lists of objects and their events within the VBA IDE. That would be a perfectly acceptable way to handle it AFAIC.
As Pat commented, the main reason for this is to avoid project variables from being lost before you get the chance to cancel if using a form's events. That said, it would also be a cleaner and more intuitive interface which means fewer developers get confused by it and introduce errors into their designs.
Good point Pat. That is definitely what I intended, but did not specifically state.
Pat Hartman commented
I would like to add (just in case it isn't obvious) that the event should fire immediately so that it fires BEFORE any of the shut down process has started so that choosing to cancel the event leaves the app in the state it was in before the button was pushed.