Hide/disable Close button

[helenp]

We're having ongoing problems with our db that may be
coming from people closing the application without first
closing the db. I've programmed a big red EXIT button on
the interface, but people ignore it and use the familiar
close button on Access instead. Is there any way to hide
or disable the tempting red X?

Thanks,
Helen

 

[Rick B]

Do a search. This has been asked and answered at least three times in the
last few days.

 

[helenp]

Sorry, I did a search first and didn't find it. I'll try
again.

Helen

 

[Immanuel Sibero]

Helen,

What would be an example of problems created by users clicking the "X" to
close the app?
Do you do some kind of housekeeping/maintenance routine that you put in your
customized "Close" button (i.e. what you refer to as "closing the db")?

You could have a form (i.e. just a dummy form) that you open as a
hidden/invisible form everytime the app is launched. Put your closing
routine on the On Close event of this form. This dummy form will be always
be open but invisible for the duration of the user's session. When the user
clicks "X", Access will close this invisible form and the On Close event
will fire.

I use this phantom form all the time. It allows me to do closing routine if
necessary. But more than that, there are other benefits such as declaring
and holding global variables, and for performance reason (i.e. the very much
discussed "keeping a recordset open to enhance performance").


Immanuel Sibero

 

[helenp]

Thanks, Immanuel. I'm still searching for the previous
messages on this subject. One thing we seem to be running
into is minor corruption creeping in when the app is
closed with the db still open. We'll be addressing this
by going to a distribution of copies of the front end as
soon as we get some things in place (we're still fixing
our network after an incompentent original setup), but
that may be a while. In the meantime, a macro attached to
the Exit button closes the db, then the app. We also had
some security issues with people going around the
custom .mdw, but this may be ok now that the database
container is hidden, so they have to close Access to
close the db.

I'm still learning Access programming, mostly on my own,
so I appreciate the help. This trial and error can kill
you! I'll try a phantom form, see if that does what I
need.

Helen

 

[Bas Cost Budde]

In the meantime, a macro attached to
the Exit button closes the db, then the app.

What is that supposed to mean, the db and the app separate? I see the
combination of them in an Access mdb.
Do you open a separate connection to a database?

You *can* have a front end and a back end (meaning, one file with all
forms, reports, queries and code--the front end--and one file with all
tables--the back end--; the front end contains links to tables in the
back end. For instance.

I'm still learning Access programming, mostly on my own,
so I appreciate the help. This trial and error can kill
you! I'll try a phantom form, see if that does what I
need.

That form is a good approach anyway. As long as you're learning, which
may be forever ;-), keep on asking! When I started with Access I wasn't
aware of Usenet and I am sure that has lengthened my learning time quite
a lot.

 

[Guest]

People here often close the database window with its own
little red X, which closes the file, but leave the Access
program itself open and come back and open the original
or another database file using the File menu. The
default .mdw kicks in when they reopen the db this way.
It helps to hide the database container and force them to
use an interface. I'm mostly right now trying to stem
this creeping corruption, and we've seen it show up
particularly after closing with the X instead of the
macro. Maybe it's much ado about nothing, and it's
coincidence, but I'm run ragged trying to keep up with
(or ahead of) the problems this one group of users keeps
creating, so that I don't have time to fix the real
design problems. Sigh. They really just want Works back
(shudder...). Serve 'em right if I gave it to them.

The front-end/back-end split is saving my sanity. And
possibly my job.

Thanks again.

Helen

 

[Bas Cost Budde]

People here often close the database window with its own
little red X, which closes the file, but leave the Access
program itself open and come back and open the original
or another database file using the File menu. The
default .mdw kicks in when they reopen the db this way.
It helps to hide the database container and force them to
use an interface. I'm mostly right now trying to stem
this creeping corruption, and we've seen it show up
particularly after closing with the X instead of the
macro. Maybe it's much ado about nothing, and it's
coincidence, but I'm run ragged trying to keep up with
(or ahead of) the problems this one group of users keeps
creating, so that I don't have time to fix the real
design problems. Sigh. They really just want Works back
(shudder...). Serve 'em right if I gave it to them.

The front-end/back-end split is saving my sanity. And
possibly my job.

Soo, they close the *database container window*. I see.
Most uses of the hidden form prevent closing Access; but you could turn
it around and issue a Quit when you're closed. I mean that form. That
way they never have an 'open' Access.

I doubt any corruption results from closing the database container.
Maybe you've set some objects and not set them to Nothing afterwards?
Especially with Database variables this is important.

 

[Guest]

If they close the database container window, _then_ quit
Access, it doesn't seem to be a problem. That's what the
macro does. It's when both are closed simultaneously that
it seems to be a problem. And maybe it's not, and I just
haven't seen a less obvious commonality, but I've seen it
during testing and on a couple smaller databases here as
well. I'm sure there's something else that's the primary
problem, that maybe comes into play when that happens,
which I could fix if I knew how.

You've lost me with the rest. Sorry. Can you point me
to a resource that can explain it further for me?

Thanks!

Helen

 

[Bas Cost Budde]

You've lost me with the rest. Sorry. Can you point me
to a resource that can explain it further for me?

www.mvps.org/access is a great source. It doesn't address the pointer
problem I hinted immediately.

But if you don't recognize about setting objects, you probably didn't
apply programming techniques in that direction.

What kind of corruption do you experience, in fact?

 

[helenp]

Back when I used wizards to set up command buttons,
individual buttons would stop working, and the wizard
would no longer work to create more. I program the
buttons directly now using macros, which has vastly
increased their reliability. Some of the macros have
become erratic, working most of the time but suddenly
freezing up in mid session, and some forms intermittently
refuse to allow people in the proper security groups to
enter or change data. If the user closes out of the
database, the function is usually restored... for a
while, sometimes only a record or two. I'm working on an
update, so we're just living with it for now, but of
course it's the people with short fuses it happens to...
Things work fine on the table level, queries function ok,
the major forms work, just sometimes not the ones this
one department uses for data entry. They're addicted to
double-clicking everything, too, which seems to add to
some of the problems, and won't learn basic Access record
navigation to get around. Bah, humbug!

 

[Bas Cost Budde]

They're addicted to
double-clicking everything, too, which seems to add to
some of the problems

have a Static integer in the Click handler, increment on entry, and if