By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
446,391 Members | 1,926 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 446,391 IT Pros & Developers. It's quick & easy.

Bypass a Close Application MessageBox

P: n/a
Sometimes users (including myself) accidentally click on the application
close icon in the application menu bar when they meant to just click on the
'X' for the form. Of course the app closes and this is very annoying.

So, I added a messagebox to my hidden StartAppForm in the Unload event. Now
when the application closes the user is presented with a message so they can
abort closing in case they don't really want to close. This has been working
very well.

However, I forgot that there are cases where I want to force a shutdown
regardless of what the user wants (i.e. user doesn't agree to license, etc).
I'm using either DoCmd.Quit or Application.Quit in these instances. When this
happens, the afore-mentioned messagebox appears "Do you really want to close
the application" with a Yes/No button. Regardless of what the user selects,
the app closes. While this is not a showstopper and an events occur as I want
them to, the appearance of this messagebox in this case looks unprofessional.

So I thought I would just add a global boolean variable: BypassCloseMessage.
This variable would be set to True just before any DoCmd.Quit or Application.
Quit code statement. Then in the hidden StartAppForm Unload event, the code
would check the value of this global boolean variable. If True, bypass the
messagebox and continue closing.

I thought that this would work. However, it doesn't. I've checked the code
and it looks correct.

When using the DoCmd.Quit or Application.Quit command, does this cause the
global variables to go out of scope immediately. I tried putting a break in
the StartAppForm Unload event, but the code won't stop there after the DoCmd.
Quit or Application.Quit command has been invoked. The application closes and
disappears from the screen. BUT, the messagebox "Do you really want to close
the application" does appear as the last thing on the screen (even though the
rest of the app is no longer viewable). Regardless of what the user selects
it is then closed.

So how can I solve my problem and it would be great if someone could explain
why this behaviour is occurring.

Thanks

--
Message posted via AccessMonster.com
http://www.accessmonster.com/Uwe/For...ccess/200612/1

Dec 3 '06 #1
Share this Question
Share on Google+
3 Replies


P: n/a
I think I've found the solution.

After some more research I discovered discussions where the Quit command
causes global variables to go out of scope, which is what I seem to be
experiencing.

So instead of setting a global variable. I have now added a checkbox to my
StartAppForm, which I set to True just prior to calling the DoCmd.Quit
command.

Now everything seems to be working fine, but I need to do more testing. I
should have coded it this way earlier, since I'm trying to get away from
global variables.

rdemyan wrote:
>Sometimes users (including myself) accidentally click on the application
close icon in the application menu bar when they meant to just click on the
'X' for the form. Of course the app closes and this is very annoying.

So, I added a messagebox to my hidden StartAppForm in the Unload event. Now
when the application closes the user is presented with a message so they can
abort closing in case they don't really want to close. This has been working
very well.

However, I forgot that there are cases where I want to force a shutdown
regardless of what the user wants (i.e. user doesn't agree to license, etc).
I'm using either DoCmd.Quit or Application.Quit in these instances. When this
happens, the afore-mentioned messagebox appears "Do you really want to close
the application" with a Yes/No button. Regardless of what the user selects,
the app closes. While this is not a showstopper and an events occur as I want
them to, the appearance of this messagebox in this case looks unprofessional.

So I thought I would just add a global boolean variable: BypassCloseMessage.
This variable would be set to True just before any DoCmd.Quit or Application.
Quit code statement. Then in the hidden StartAppForm Unload event, the code
would check the value of this global boolean variable. If True, bypass the
messagebox and continue closing.

I thought that this would work. However, it doesn't. I've checked the code
and it looks correct.

When using the DoCmd.Quit or Application.Quit command, does this cause the
global variables to go out of scope immediately. I tried putting a break in
the StartAppForm Unload event, but the code won't stop there after the DoCmd.
Quit or Application.Quit command has been invoked. The application closes and
disappears from the screen. BUT, the messagebox "Do you really want to close
the application" does appear as the last thing on the screen (even though the
rest of the app is no longer viewable). Regardless of what the user selects
it is then closed.

So how can I solve my problem and it would be great if someone could explain
why this behaviour is occurring.

Thanks
--
Message posted via AccessMonster.com
http://www.accessmonster.com/Uwe/For...ccess/200612/1

Dec 3 '06 #2

P: n/a
rdemyan via AccessMonster.com wrote:
I think I've found the solution.
My solution has been to keep my applications very, very simple. I have
not written very much that saves a user from himself/herself. My
clients (past as I am no longer in business) have always liked this. So
have I.

Dec 3 '06 #3

P: n/a
Append the BypassCloseMessage to the messagebox so you can see if it is true
or false.
By definition, a gobal variable is global AS LONG AS ITS NOT IN A PROCEDURE.
stick it right at the top of a module, not on a form either.
everythng else you have done seems logical.

"rdemyan via AccessMonster.com" <u6836@uwewrote in message
news:6a3736d9bd68c@uwe...
Sometimes users (including myself) accidentally click on the application
close icon in the application menu bar when they meant to just click on
the
'X' for the form. Of course the app closes and this is very annoying.

So, I added a messagebox to my hidden StartAppForm in the Unload event.
Now
when the application closes the user is presented with a message so they
can
abort closing in case they don't really want to close. This has been
working
very well.

However, I forgot that there are cases where I want to force a shutdown
regardless of what the user wants (i.e. user doesn't agree to license,
etc).
I'm using either DoCmd.Quit or Application.Quit in these instances. When
this
happens, the afore-mentioned messagebox appears "Do you really want to
close
the application" with a Yes/No button. Regardless of what the user
selects,
the app closes. While this is not a showstopper and an events occur as I
want
them to, the appearance of this messagebox in this case looks
unprofessional.

So I thought I would just add a global boolean variable:
BypassCloseMessage.
This variable would be set to True just before any DoCmd.Quit or
Application.
Quit code statement. Then in the hidden StartAppForm Unload event, the
code
would check the value of this global boolean variable. If True, bypass the
messagebox and continue closing.

I thought that this would work. However, it doesn't. I've checked the code
and it looks correct.

When using the DoCmd.Quit or Application.Quit command, does this cause the
global variables to go out of scope immediately. I tried putting a break
in
the StartAppForm Unload event, but the code won't stop there after the
DoCmd.
Quit or Application.Quit command has been invoked. The application closes
and
disappears from the screen. BUT, the messagebox "Do you really want to
close
the application" does appear as the last thing on the screen (even though
the
rest of the app is no longer viewable). Regardless of what the user
selects
it is then closed.

So how can I solve my problem and it would be great if someone could
explain
why this behaviour is occurring.

Thanks

--
Message posted via AccessMonster.com
http://www.accessmonster.com/Uwe/For...ccess/200612/1

Dec 4 '06 #4

This discussion thread is closed

Replies have been disabled for this discussion.