Quite simply, I don't like it, but let me explain.
Point #1: As John already pointed, you better have rock solid error handling procedures throughout your application. This is a good idea in any app, but here it is absolutely vital. An Access app that has to have a manual End Task is at far greater risk of database corruption.
Point #2: Try this - Open your app so the form is showing. Now in most user's Quick Launch Toolbar there is an option called "Show Desktop." Click that button and watch what happens......I'll wait, go ahead and try it......Do you think it is possible your users might do that? Not worth the risk in my opinion.
Point #3: Good luck trying to print preview any reports using this technique! Since all your forms have to be Popup, the reports will have a little bit of an *issue* with this.
Point #4: Simply having all forms Popup and Modal set to True can be somewhat of a challenge making sure everything functions properly.
Most of the time when I see people wanting to use this technique (myself included in years past) they list one of two reasons (or both):
1. They do not want their app to look like an Access application (or make it not obvious it was created using Access).
2. They do not want users choosing options they should not be.
Both of these issues can be solved by using better techniques. The best option is to create custom menu bars and toolbars to hide the main Access ones. You simply present to the users the options *you* want them to see. If you don't want them to press the Delete Record button on the toolbar, then don't show them one! Creating custom menu bars and toolbars can actually be quite fun. In addition, it puts a nice polish on your application and makes it look very professional. Instead of your database looking like an Access file, it will now look like a Windows *application*. Utilize the Tools | Startup options to further customize things so users see what you want them to see.
For information on creating custom menu bars and toolbars, see this area of my Resources page:
http://home.bendbroadband.com/conradsystems/accessjunkie/resources.html#MenuBars
On the flip side, I have seen cases where something like this code can come in handy. The general rules of thumb I like to give out is that:
A. The application has only a few data entry forms to deal with.
B. This is not a mission critical app in case database corruption occurs from a "hang."
C. You do not need to view ANY reports on screen.
Here are two examples for you:
1. I use this for creating a customized login screen to a secured database file. The unsecured file is virtually a throw away file so if something bad happens to it, I don't lose any data. You can read my article and download a sample file here:
http://www.access.qbuilt.com/html/custom_login.html
2. Using the database for like a kiosk situation (like in a mall) where the user will simply be interacting with one or a couple of forms. Possibly even with a touch screen interface.
Hope that helps,
--
Jeff Conrad
Access Junkie - MVP
