Disable Window Close Button

[Pat Hartman]

@KitaYama I read your explanation. YOU think you need to control the process by controlling the "x". I disagree.

We cannot forget that there are no update events on an unbound form,

That is correct. My POINT which everyone seems to be missing, is that ultimately, the developer does NOT have the final control over whether or not the app closes. You can try your darndest to stop Access from closing but in the end, you can't. Therefore, maybe, there might be a better option. We have no idea what prompted this question and we are unlikely to get a business case for the request so we are working without a net.

When the typical poster wants to stop Access from closing, it is because he doesn't understand how to use form events correctly so he is trying to enter "God mode" by stopping Access from closing, thinking that is the "solution"

Perhaps @stu_c knows more than what is indicated by the question. However, since he is using macros, it is not likely he is well versed in how to control Access.

You have all done your duty. You answered the SPECIFIC question that was asked and JUSTIFIED why preventing Access from closing is valid. OK, I give up. The OP will go away happy because he thinks he stopped Access from closing until the method fails due to something beyond his control. Users do some seriously stupid things. I had one who figured out how to put the Shrinker/Stretcher code into an infinite loop and crash Access. I had one programmer who brought down the entire CICS test region by trying to stop the user from closing the app without finishing which was actually really good because if he hadn't, his code would have gone into production where it would have brought 4,000 users crashing down the first time someone tried to exit out of the form without finishing.

 

[The_Doc_Man]

The OP will go away happy because he thinks he stopped Access from closing until the method fails due to something beyond his control. Users do some seriously stupid things.

Which is why I included the comment when I posted the links regarding that he should read the WHOLE ARTICLE, which had a lengthy discussion about the wisdom of the "disable the X" operation. Pat, you and I agree that the design seems somehow "off" and probably is unwise, but in the final analysis, sometimes the little birds have to fly from the nest on their own - without a net - learning that the fall from that height is painful. Besides, I really don't like the "nurturing the little birds" analogy that much because it would imply that I eat worms. Yecchh! Vermicelli, maybe. Worms? Nope.

 

[JonXL]

I've never disabled the close operation (which I think might need more than just hiding the X - to handle shortcuts), but I do use a method in line with the nav/hidden form approach mentioned by several here to present users an "are you sure?" so they don't accidentally close and get frustrated having to reopen (for example, if just trying to move the window).

In the world of Access, hoping your DB never closes unexpectedly is a rather risky approach to managing data integrity...

 

[The_Doc_Man]

I actually preferred to use the method of catching the Unload event, which can be canceled. If you cancel the Unload, clicking that X doesn't matter. Oh, sure, the user can step out to the desktop, run Task Manager, and close the app - but at least in that case you know that is what the user really wanted to do, despite the barriers you tossed in the way.

Of course, I always popped up a message box in that case, explaining that you can't close the form while it is still dirty, and further advising that you could use the command buttons built into the form, to Save or Cancel what you were doing, after which that X would work normally. Or you could use the Close button on that form and then on the parent. Far easier mechanically. All it took was a matter of user education. And if the form wasn't dirty, its upper-right X WOULD work. As would the dispatcher form's X.

 

[Pat Hartman]

If you feel the need to control whether or not the user pushes your save button, you can do that fairly easily but it does require at least one line of code in four form level events but that's for every form. It becomes second nature. It is the first thing you do when you create a form. If you use templates for your forms, the code is in the template. Removing the X is like using a bazooka to kill a fly.

Here's my response to a question about prompting on every form and every record before saving.

Prompting to save/not save on every record rapidly becomes annoying to users and they will start blowing by your messages without reading them. Don't do it.

If you want to have more control over saving because your users are actually as stupid and careless as they look or you haven't bothered with sound data validation in the form's BeforeUpdate event, then you need to add save buttons to both the main form and the subform.

The following instructions apply to both the main and the subform. You need buttons and code in BOTH.
1. Create a public variable Dim'd as Boolean in the header of each form to record the push of the save button. Name it bSaveButton
2. In the Current event of the form, set bSaveButton to False
3. In the Click event of the save button, set bSaveButton to True
4. In the BeforeUpdate event of the FORM, check the value in bSaveButton. If the value is False, ask the user if he wants to save. If he clicks No, cancel the update and exit the procedure.
5. In the AfterUpdate event of the form set bSaveButton to False

This allows you to force the user to use the save button but you don't bother him with gratuitous messages when he does the right thing. You only bother him when he does the wrong thing. This is much more effective and does not desensitize the user because you are not bombarding him with messages he doesn't need to see.

 

[ebs17]

save button

This has not yet been discussed, but it is suitable to continue the discussion with a further 13 contributions and to increase the "popularity" of the topic.