Closing Forms (1 Viewer)

[tmyers]

This is a best practice question.

Should there be a module that, when someone just closes the DB via say the X in the top corner, to handle all the forms closing and unloading? I have a couple users that love to just close the DB when they are done rather then backing out of it and closing it like I would expect a normal person to. Most of my forms open and close each other while setting focus back and forth so when this is done it causes a bunch of errors I have to try and manage so it doesn't just go haywire on the person.

I figured trying to outright disable the close button wouldn't be a good design (if it can be done) as I don't like overriding basic Windows functions.

 

[theDBguy]

If closing the app causes errors, then perhaps it's not about best practice but more of a necessity for you.

 

[Pat Hartman]

When you close the app with the "x", the forms are unloaded gracefully as if you closed each one in turn.. This is not, nor should it be, a hard close. Last opened, first closed is the normal order of events. The problem arises if there is an abrupt power off or a freeze and a forced closure and neither of these can be handled gracefully by your code because your code won't run so you can't program for this eventuality.

The only problem with using the "x" to close is if you have code which forces people to do something a specific way.

Personally, I rarely allow multiple forms to be open at the same time to start with but if I do, they won't be adversely impacted by the last open first close sequence used by the "x". Each form needs to take care of itself. If it does, then closing using the "x" will not have any adverse effects.

There are situations where I want certain things to happen when the db closes. If that is the case, I control it by opening the shut down form as the FIRST form the app opens which will always make it the LAST form that Access closes during a controlled shutdown. The shut down form, when opened initially, just hides itself and opens the application menu or login form. Then as part of the normal close either by the user clicking one at a time or by starting with the "x" and Access clicking one at a time, eventually the shut down form gains the focus and as part of its unload or close event, you run your "backup" or "version update" or "email results" or "whatever" process you want to run at shut down.

Easy when you know how

Do not code dependencies when you can do things the "Access" way

 

[The_Doc_Man]

The "best practice" issue is "purity of purpose." If a form has a purpose, it rarely or never should depend on another form. The exceptions are, of course, sub-form cases, dispatcher forms, and switchboard forms, and the occasional pop-up. But two forms, neither of which are in my exceptions list, should never depend on each other. You get virtual spaghetti code with all those external cross-dependencies.

When you say that your forms open and close each other, you are introducing cross-form dependencies which can lead to a broken chain of dependencies when someone does something out of sequence. According to Murphy's Law, what CAN go wrong WILL go wrong. Murphy's Corollary is, make it so that it cannot go wrong in the first place.

 

[tmyers]

I model a lot of my forms from Northwind where they have "hyperlinked" fields to click that open other forms. I have started using buttons/combos more and more however to handle navigation due to the problems I described in OP with my current methods.

 

[isladogs]

If you are basing your forms on those in the older Northwind dating from A2007 or earlier, there are many issues that will cause problems

 

[moke123]

Most of my forms open and close each other while setting focus back and forth so when this is done it causes a bunch of errors

What kinds of errors?

 

[Galaxiom]

You could disable the Application Window Close button. There is code on this site to show how it is done with an API call.

 

[tmyers]

You could disable the Application Window Close button. There is code on this site to show how it is done with an API call.

I had looked at that but I don't like disabling things that people generally expect to work as I think it makes things even more clunky in the long run.

If you are basing your forms on those in the older Northwind dating from A2007 or earlier, there are many issues that will cause problems

Should I not use the current Northwind as a reference point? I liked the layout of the forms for the most part and how the navigation was done. I have not used or, intentionally at least, replicated/used code from it.

 

[isladogs]

I was deliberately referring to the old Northwind versions
The new Northwind 2.0 templates are MUCH better. Hopefully using those wouldn't cause any problems

Another possible approach is to hide the Access application interface completely.
You will no longer see the title bar or items such as the close button.

 

[tmyers]

I believe the version I have is the old one. Now as to which version, I am not entirely sure. I do use code to hide the ribbon and such that I found from one of your post but I wont implement it until the DB is ready to distribute.

Out of the couple Access apps I have made (or butchered depending on view), this one I am hoping to actually post when it is decently functional for you all to critique and see how I did, which hopefully wont be terribly bad

 

[Galaxiom]

I had looked at that but I don't like disabling things that people generally expect to work as I think it makes things even more clunky in the long run.

Some developers hide the Application window completely and just show the forms and reports. That way users don't actually realise anything is missing.

 

[tmyers]

Some developers hide the Application window completely and just show the forms and reports. That way users don't actually realise anything is missing.

Ive used Isla's code for that as well. I haven't managed to get it to work without being really clunky though.

 

[isladogs]

Ive used Isla's code for that as well. I haven't managed to get it to work without being really clunky though.

It can be more challenging to code where the interface is removed.
However if this is planned from the start it works well in my experience. Things get more problematic when you try to do this with a long established application which was never intended for that purpose.

 

[Pat Hartman]

I model a lot of my forms from Northwind where they have "hyperlinked" fields to click that open other forms.

A straightforward, non dependent interface is always best. If you have multiple paths to any given form, you have spaghetti code. Normally, you should only get to a form from the menu/switchboard. Occasionally, you will have a popup form but there should be only one main form that opens the popup.

Having an interface where multiple forms remain open at one time becomes confusing to the user since they don't remember how they got "here". The new version of Northwind allows (for some forms but not all) multiple instances of the same form to be open at the same time. I won't argue with this since there are use cases where this makes sense. I would never do it just because I can. I would ONLY do it if the user specifically identifies a use case where the functionality is necessary.