Trapping access close button

[Jess]

I have a form and a subform.

If I click on any of the textboxes on my subform and then on the 'close
window' or 'access close' button, the subform container exit event fires
first -assuming no updates have taken place.

In my application, the subform container exit event must know whether the
close window button has been clicked or not. This is due to reasons long to
explain.

The beforeupdate is not the solution since my subform or mainfom may not be
dirty.

Is there a way/event/property aware of the 'close window' button having been
clicked?

Thanks

 

[Jack Leach]

This is a tough one.

I'm not sure if there is any other way out than the close button for you,
but if there is you can differentiate by setting a flag variable when exiting
by any other means than the form close button. For instance, if you have
separate Exit button, on that click you could set a boolean variable that's
private to the form's module. Then in the unload event of the mainform, you
can check that flag variable to see if the form is being closed by an Exit
button as opposed to the form's control box Close button.

If required, it is possible to call an event procedure located in the
subform from a separate module. So, if you wanted to run the Exit event of
the subform, from the unload event of the mainform, you could doso like this:

Me.subformcontrol.Form.Form_Exit

For this to work you need to change the declaration of the sub in the
Form_Exit event. Change Private Sub Form_Exit() to Public Sub Form_Exit.

This is obviously not the most ideal way to go about this (I don't think
there is an ideal way), and will only work on certain conditions that may be
hard to pin down themselves.

I would recommend give Dale's suggestion from your previous post on the
subject some serious consideration. If the user is not allowed to close the
form via the Control Box Close button, it makes it much easier to manipulate
what happens when the form is closing. Even this, though, will not work
seamlessly if the form is closed by any methods other than what you provide
as a replacement (ex if the form is closed via code or by an expected (or
unexpected) shutdown of access).

Putting your own exit button and removing access's builtin form exit button
has a number of advantages.

hth
--
Jack Leach
www.tristatemachine.com

"I haven't failed, I've found ten thousand ways that don't work."
-Thomas Edison (1847-1931)

 

[Jack Leach]

This is a tough one.

I'm not sure if there is any other way out than the close button for you,
but if there is you can differentiate by setting a flag variable when exiting
by any other means than the form close button. For instance, if you have
separate Exit button, on that click you could set a boolean variable that's
private to the form's module. Then in the unload event of the mainform, you
can check that flag variable to see if the form is being closed by an Exit
button as opposed to the form's control box Close button.

If required, it is possible to call an event procedure located in the
subform from a separate module. So, if you wanted to run the Exit event of
the subform, from the unload event of the mainform, you could doso like this:

Me.subformcontrol.Form.Form_Exit

For this to work you need to change the declaration of the sub in the
Form_Exit event. Change Private Sub Form_Exit() to Public Sub Form_Exit.

This is obviously not the most ideal way to go about this (I don't think
there is an ideal way), and will only work on certain conditions that may be
hard to pin down themselves.

I would recommend give Dale's suggestion from your previous post on the
subject some serious consideration. If the user is not allowed to close the
form via the Control Box Close button, it makes it much easier to manipulate
what happens when the form is closing. Even this, though, will not work
seamlessly if the form is closed by any methods other than what you provide
as a replacement (ex if the form is closed via code or by an expected (or
unexpected) shutdown of access).

Putting your own exit button and removing access's builtin form exit button
has a number of advantages.

hth
--
Jack Leach
www.tristatemachine.com

"I haven't failed, I've found ten thousand ways that don't work."
-Thomas Edison (1847-1931)

 

[Tom van Stiphout]

On Tue, 12 May 2009 05:56:01 -0700, Jess

What you are experience is punishment for going against the grain.
This is often counter-productive. There must be a way to reorganize
your code so that everything happens the way it should. Perhaps one of
the flaws in the current thinking is that you can capture that Close
Window click, whereas you can only respond to an event when the window
is closing, by whatever means that can be accomplished.

-Tom.
Microsoft Access MVP

 

[Tom van Stiphout]

On Tue, 12 May 2009 05:56:01 -0700, Jess

What you are experience is punishment for going against the grain.
This is often counter-productive. There must be a way to reorganize
your code so that everything happens the way it should. Perhaps one of
the flaws in the current thinking is that you can capture that Close
Window click, whereas you can only respond to an event when the window
is closing, by whatever means that can be accomplished.

-Tom.
Microsoft Access MVP