473,473 Members | 1,842 Online
Bytes | Software Development & Data Engineering Community
Create Post

Home Posts Topics Members FAQ

How to prevent Access from closing

I have a form which the user must complete before closing. I have
disabled the window x button and use my own exit button. When selected
it checks to see if the user has completed the entries otherwise it
cancels the close.
However, the user can still right click on the task bar and close my
application.
Is there any way of preventing this.
Thanks
Alex

Nov 13 '05 #1
22 7517
Put logic in the form's Unload event to check whether the form has been
completed or not. If it hasn't, set Cancel = True, and the form won't be
able to close, thereby keeping the application from closing.

--
Doug Steele, Microsoft Access MVP
http://I.Am/DougSteele
(no e-mails, please!)

<al********@hotmail.com> wrote in message
news:11**********************@g43g2000cwa.googlegr oups.com...
I have a form which the user must complete before closing. I have
disabled the window x button and use my own exit button. When selected
it checks to see if the user has completed the entries otherwise it
cancels the close.
However, the user can still right click on the task bar and close my
application.
Is there any way of preventing this.
Thanks
Alex

Nov 13 '05 #2
This does not stop the user from right clicking on the taskbar button
and selecting close to close it.
Alec

Nov 13 '05 #3
No, there's no (reliable) way to prevent this. When all else fails,
users *will* yank the power cord from the machine.

It is a _really_ bad idea to require users to do things before they can
close your form or application. Instead, provide your users with a way
to "back out" of what they were doing, and/or a way to get back where
they were when they had to stop.

Nov 13 '05 #4
This is a time sheet application and the users must complete it. I can
get the form to open as required but the client is requesting that the
users should not be able to 'opt out' of completing it in any way. My
form will not close but users have found that they can close it from
the task bar.
Is there any solution to this?
Alec

Nov 13 '05 #5

<al********@hotmail.com> schreef in bericht news:11*********************@g14g2000cwa.googlegro ups.com...
This is a time sheet application and the users must complete it. I can
get the form to open as required but the client is requesting that the
users should not be able to 'opt out' of completing it in any way. My
form will not close but users have found that they can close it from
the task bar.
Is there any solution to this?
Alec


I don't think you can prevent users to close the app one way or another.
If you would find a registry-hack or so for the taskbar-rightclick-option, your users still could do a Ctrl-Alt-Delete I guess...
I agree with Chuck on this.

I bet your client wants something like: If there are records, they must be 'completed'.
You *can* require users to do things before you SAVE the record, so you can achieve what your client wants.

Arno R
Nov 13 '05 #6
al********@hotmail.com wrote in
news:11*********************@g14g2000cwa.googlegro ups.com:
This is a time sheet application and the users must complete it. I
can get the form to open as required but the client is requesting
that the users should not be able to 'opt out' of completing it in
any way. My form will not close but users have found that they can
close it from the task bar.
Is there any solution to this?


Explain to the client that it's just not possible, and you're going
against human nature to try to prevent it.

The solution is to have graceful cleanup and to allow them to opt
out of finishing the timesheet. That means one of two things:

1. erasing all record of it, OR

2. recording the abandoned creation (so data isn't lost), and then
erasing it, OR

3. recording the abandoned add and requiring them to complete it the
next time they start up the app.

I'm all for #3, myself, if you really are going to enforce the rule.

But if not, I'd say you should let the user abandon the record, but
they would have to record a *reason* for abandoning it. You'd then
move it to a table for abandoned records, and an administrator could
then review it and take action as necessary.

Overall, it's an administrative problem. Software can't force people
to do their jobs right. If it attempts to, you'll get garbage data
in the end, because people will put in anything just to get out of
it.

This all reminds me of the past clients of mine who would remove
Solitaire from their employees' PCs, as if that's the only way to be
nonproductive. This was a problem for me, because in the days when I
was training people to transition from DOS to Windows, Solitaire was
a necessary tool for helping people become comfortable with mouse
operations -- I made it a required exercise between the 1st and 2nd
lessons to spend 30 minutes playing Solitaire. And, of course,
playing Solitaire is like a coffee break for some people. Only a
company that really wants to fail will prevent its employees from
taking needed breaks, and that company will see reduced productivity
as a result.

Of course, I also think that a well-managed organization will
measure performance based on whether the assigned work gets done
properly on time, not by whether or not somebody filled out every
timesheet they started, or whether they spent 15 minutes playing
Solitaire to unwind.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
Nov 13 '05 #7
The users MUST complete time sheets on a daily basis. If they do not any
billing will be inaccurate. I have a report which shows who has not
completed a timesheet but this does not make sure that each user completes
the time sheet. The system does not worry about today since that is on going
and may be completed anytime today or tomorrow. Ths system does check for
all previous days time sheet entries and requests that they be completed.
Each user has a required number of hours to complete. I can open the form
periodically to inconvenience them into doing it but users still just close
by right clicking ont eh taskbar entry and selecting close.
The fact that the time sheet is on the screen is not an inconvenience since
users can still work with other applicaitons.
There is good reason to want to prevent a user from closing it.
Alex
"David W. Fenton" <dX********@bway.net.invalid> wrote in message
news:Xn**********************************@24.168.1 28.78...
al********@hotmail.com wrote in
news:11*********************@g14g2000cwa.googlegro ups.com:
This is a time sheet application and the users must complete it. I
can get the form to open as required but the client is requesting
that the users should not be able to 'opt out' of completing it in
any way. My form will not close but users have found that they can
close it from the task bar.
Is there any solution to this?


Explain to the client that it's just not possible, and you're going
against human nature to try to prevent it.

The solution is to have graceful cleanup and to allow them to opt
out of finishing the timesheet. That means one of two things:

1. erasing all record of it, OR

2. recording the abandoned creation (so data isn't lost), and then
erasing it, OR

3. recording the abandoned add and requiring them to complete it the
next time they start up the app.

I'm all for #3, myself, if you really are going to enforce the rule.

But if not, I'd say you should let the user abandon the record, but
they would have to record a *reason* for abandoning it. You'd then
move it to a table for abandoned records, and an administrator could
then review it and take action as necessary.

Overall, it's an administrative problem. Software can't force people
to do their jobs right. If it attempts to, you'll get garbage data
in the end, because people will put in anything just to get out of
it.

This all reminds me of the past clients of mine who would remove
Solitaire from their employees' PCs, as if that's the only way to be
nonproductive. This was a problem for me, because in the days when I
was training people to transition from DOS to Windows, Solitaire was
a necessary tool for helping people become comfortable with mouse
operations -- I made it a required exercise between the 1st and 2nd
lessons to spend 30 minutes playing Solitaire. And, of course,
playing Solitaire is like a coffee break for some people. Only a
company that really wants to fail will prevent its employees from
taking needed breaks, and that company will see reduced productivity
as a result.

Of course, I also think that a well-managed organization will
measure performance based on whether the assigned work gets done
properly on time, not by whether or not somebody filled out every
timesheet they started, or whether they spent 15 minutes playing
Solitaire to unwind.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

Nov 13 '05 #8
"Paradigm" <al********@hotmail.com> wrote in
news:w2*****************@newsfe1-gui.ntli.net:
The users MUST complete time sheets on a daily basis. If they do
not any billing will be inaccurate. I have a report which shows
who has not completed a timesheet but this does not make sure that
each user completes the time sheet. The system does not worry
about today since that is on going and may be completed anytime
today or tomorrow. Ths system does check for all previous days
time sheet entries and requests that they be completed. Each user
has a required number of hours to complete. I can open the form
periodically to inconvenience them into doing it but users still
just close by right clicking ont eh taskbar entry and selecting
close. The fact that the time sheet is on the screen is not an
inconvenience since users can still work with other applicaitons.
There is good reason to want to prevent a user from closing it.


I disagree. There is *no* good reason to force someone into a
position where they can't control your application.

And it's an impossible task, in any case -- you can't do it -- so
I'd say you'd be better off rethinking the whole operation.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
Nov 13 '05 #9
For what its worth, and that's not much, I completely agree. There is
nothing more annoying than the software tail wagging the, err, business dog.
Perhaps you can introduce a carrot or two for timely completion of your
timesheets?

Paul
"David W. Fenton" <dX********@bway.net.invalid> wrote in message
news:Xn**********************************@24.168.1 28.86...
"Paradigm" <al********@hotmail.com> wrote in
news:w2*****************@newsfe1-gui.ntli.net:
The users MUST complete time sheets on a daily basis. If they do
not any billing will be inaccurate. I have a report which shows
who has not completed a timesheet but this does not make sure that
each user completes the time sheet. The system does not worry
about today since that is on going and may be completed anytime
today or tomorrow. Ths system does check for all previous days
time sheet entries and requests that they be completed. Each user
has a required number of hours to complete. I can open the form
periodically to inconvenience them into doing it but users still
just close by right clicking ont eh taskbar entry and selecting
close. The fact that the time sheet is on the screen is not an
inconvenience since users can still work with other applicaitons.
There is good reason to want to prevent a user from closing it.


I disagree. There is *no* good reason to force someone into a
position where they can't control your application.

And it's an impossible task, in any case -- you can't do it -- so
I'd say you'd be better off rethinking the whole operation.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

Nov 13 '05 #10
"Paul Wagstaff" <wa***@blueyonder.co.uk> wrote in
news:mb********************@fe2.news.blueyonder.co .uk:
For what its worth, and that's not much, I completely agree. There
is nothing more annoying than the software tail wagging the, err,
business dog. Perhaps you can introduce a carrot or two for timely
completion of your timesheets?


You don't get a paycheck?

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
Nov 13 '05 #11
MS

"David W. Fenton" <dX********@bway.net.invalid> wrote in message
news:Xn**********************************@24.168.1 28.86...
"Paradigm" <al********@hotmail.com> wrote in
news:w2*****************@newsfe1-gui.ntli.net:
The users MUST complete time sheets on a daily basis. If they do
not any billing will be inaccurate. I have a report which shows
who has not completed a timesheet but this does not make sure that
each user completes the time sheet. The system does not worry
about today since that is on going and may be completed anytime
today or tomorrow. Ths system does check for all previous days
time sheet entries and requests that they be completed. Each user
has a required number of hours to complete. I can open the form
periodically to inconvenience them into doing it but users still
just close by right clicking ont eh taskbar entry and selecting
close. The fact that the time sheet is on the screen is not an
inconvenience since users can still work with other applicaitons.
There is good reason to want to prevent a user from closing it.


I disagree. There is *no* good reason to force someone into a
position where they can't control your application.

And it's an impossible task, in any case -- you can't do it -- so
I'd say you'd be better off rethinking the whole operation.


I too have a situation where I would prefer the user to exit the application
from a form, rather than by closing the application itself "mid
transaction".

The reason is that db activity is timed, and the user should "log-off" by
selecting their name when finished to enable a time stamp to be generated
against the users name. Also the user is asked whether they want to back up
or archive the db on closing.

Closing the application in a way other than from the appropriate form skips
these steps which, while not catastrophic, is undesirable.

Nov 13 '05 #12
"MS" <Em***@Myemail.com> wrote in
news:mp*****************@news-server.bigpond.net.au:

"David W. Fenton" <dX********@bway.net.invalid> wrote in message
news:Xn**********************************@24.168.1 28.86...
"Paradigm" <al********@hotmail.com> wrote in
news:w2*****************@newsfe1-gui.ntli.net:
The users MUST complete time sheets on a daily basis. If they do
not any billing will be inaccurate. I have a report which shows
who has not completed a timesheet but this does not make sure
that each user completes the time sheet. The system does not
worry about today since that is on going and may be completed
anytime today or tomorrow. Ths system does check for all
previous days time sheet entries and requests that they be
completed. Each user has a required number of hours to complete.
I can open the form periodically to inconvenience them into
doing it but users still just close by right clicking ont eh
taskbar entry and selecting close. The fact that the time sheet
is on the screen is not an inconvenience since users can still
work with other applicaitons. There is good reason to want to
prevent a user from closing it.
I disagree. There is *no* good reason to force someone into a
position where they can't control your application.

And it's an impossible task, in any case -- you can't do it -- so
I'd say you'd be better off rethinking the whole operation.


I too have a situation where I would prefer the user to exit the
application from a form, rather than by closing the application
itself "mid transaction".


Well, that's a different animal. I was arguing against the
proposition that there was some way to prevent shutting down Access
with the Task Manager, which the users were doing because they were
being forced to do things they didn't want to do.
The reason is that db activity is timed, and the user should
"log-off" by selecting their name when finished to enable a time
stamp to be generated against the users name. Also the user is
asked whether they want to back up or archive the db on closing.
Here's a suggestion:

Get the Windows user name with API calls (see
http://www.mvps.org/access/api/api0008.htm for code to do it), and
record it for them. That way, they don't have to interact with the
database in order for you to have the information you need.
Closing the application in a way other than from the appropriate
form skips these steps which, while not catastrophic, is
undesirable.


I would say that it's never wise to rely on user input to indentify
a user. It's better to use either Jet security or the Windows logon.
You can also combine the two, by logging people on with Jet security
(not password protected) using a shortcut that passes the
environment variable %USERNAME%. Then you can use the CurrentUser()
function within Access to get the Windows user name without needing
to use the API code.

But that does require have a system.mdw with everybody's Windows
username recorded in it.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
Nov 13 '05 #13
Hi Alex. There are many reasons for forcing the user to close a
particular form before they can close the database. Mine is that I run
a "logon" query when a user opens the database and I require a "logoff"
query to be run before it is closed. If I allow the user to close the
database window the "logoff" query does not run.

I'm no expert, but I found a method on this newgroup that works well.
It will stop the user closing the Access window by clicking the "X" or
by right clicking on your application's taskbar icon and choosing
"Close". They can still use the task manager to close the app however.

Create a new module called "CloseAccess" or something similar and paste
the following code into it.

Option Compare Database
Option Explicit

Public pboolCloseAccess As Boolean

Function CloseDBFalse()
On Error Resume Next
pboolCloseAccess = False
End Function

Have a form open in hidden mode when you start your application. In
the form's "On Unload" event paste the following code:

If Not pboolCloseAccess Then Cancel = True

Close your database when required by placing:

"Docmd.Quit" in the "On Close" event of your main form or switchboard.

Hope this helps.

Nov 13 '05 #14
MS

"Wayne" <cq*******@volcanomail.com> wrote in message
news:11********************@f14g2000cwb.googlegrou ps.com...
Hi Alex. There are many reasons for forcing the user to close a
particular form before they can close the database. Mine is that I run
a "logon" query when a user opens the database and I require a "logoff"
query to be run before it is closed. If I allow the user to close the
database window the "logoff" query does not run.

I'm no expert, but I found a method on this newgroup that works well.
It will stop the user closing the Access window by clicking the "X" or
by right clicking on your application's taskbar icon and choosing
"Close". They can still use the task manager to close the app however.

Create a new module called "CloseAccess" or something similar and paste
the following code into it.

Option Compare Database
Option Explicit

Public pboolCloseAccess As Boolean

Function CloseDBFalse()
On Error Resume Next
pboolCloseAccess = False
End Function

Have a form open in hidden mode when you start your application. In
the form's "On Unload" event paste the following code:

If Not pboolCloseAccess Then Cancel = True

Close your database when required by placing:

"Docmd.Quit" in the "On Close" event of your main form or switchboard.

Hope this helps.


Sounds like just what I've been looking for!
Nov 13 '05 #15
"MS" <Em***@Myemail.com> wrote in
news:wg*****************@news-server.bigpond.net.au:

"Wayne" <cq*******@volcanomail.com> wrote in message
news:11********************@f14g2000cwb.googlegrou ps.com...
Hi Alex. There are many reasons for forcing the user to close a
particular form before they can close the database. Mine is that
I run a "logon" query when a user opens the database and I
require a "logoff" query to be run before it is closed. If I
allow the user to close the database window the "logoff" query
does not run.

I'm no expert, but I found a method on this newgroup that works
well. It will stop the user closing the Access window by clicking
the "X" or by right clicking on your application's taskbar icon
and choosing "Close". They can still use the task manager to
close the app however.

Create a new module called "CloseAccess" or something similar and
paste the following code into it.

Option Compare Database
Option Explicit

Public pboolCloseAccess As Boolean

Function CloseDBFalse()
On Error Resume Next
pboolCloseAccess = False
End Function

Have a form open in hidden mode when you start your application.
In the form's "On Unload" event paste the following code:

If Not pboolCloseAccess Then Cancel = True

Close your database when required by placing:

"Docmd.Quit" in the "On Close" event of your main form or
switchboard.

Hope this helps.


Sounds like just what I've been looking for!


There's nothing innovative about the code above -- many of us have
been using that kind of thing for years. In the present discussion,
it wasn't relevant because it won't prohibit someone from force
quitting Access with the task manager, which is what I said on the
front end.

I still suggest that if you're forcing the app to stay open in order
to get user identity, then your app is very, very poorly designed.
Users should not have to indentify themselves before logging out.
You should either use Jet/Access security to keep track of users, or
pull the network login name. The user then won't have to worry about
it, and won't every be forced to jump through the hoops you're
constructing with code like the above that is basically a workaround
for an ill-chosen basic design.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
Nov 13 '05 #16
Hi David. I'm having a bit of trouble understanding where you are
coming from. Why the antagonistic tone? I know that there is nothing
innovative about the code that I posted and I also know that many of
"us" have been using it for years. Your implication here is that you
too have had a need for this code before. I'm very aware that this
code won't stop someone closing the application with the task manager.
If you read my post you will see that I said exactly that. If you read
the original post you will see that the task manager is not mentioned.
I interpreted the post to mean if the user right clicks on the
application's icon on the task bar - maybe I was wrong.

I am using the logon name when a user opens the database which gets fed
to a table and accompanying form which an administrator can open to see
who is currently logged in to the database. I require a logoff query to
be run when the user closes the database and hence I force the user to
close the app by closing the main switchboard instead of closing the
Access Window. No one has ever complained about jumping through this
"hoop".

Maybe it is "basically a workaround for an ill-chosen basic design" but
as I also said in my post, I'm no expert. I'd be the very first to
admit that I don't possess your level of expertise, but I am still able
to make a living writing databases for a string of very happy clients.

David, I have seen many worthwhile posts by yourself. I have also seen
many where you have done what you have done here ie. you assume the
position of some Access diety and flame someone like myself who was
only trying to help someone else who was seeking an answer that you
could have given them but refused to do so because you were intent on
maintaining the high moral ground.

Having said all that, I still don't understand where you are coming
from.

Nov 13 '05 #17

"Wayne" <cq*******@volcanomail.com> wrote in message
news:11**********************@o13g2000cwo.googlegr oups.com...
I am using the logon name when a user opens the database which gets fed
to a table and accompanying form which an administrator can open to see
who is currently logged in to the database. I require a logoff query to
be run when the user closes the database and hence I force the user to
close the app by closing the main switchboard instead of closing the
Access Window. No one has ever complained about jumping through this
"hoop".


You could run your query in the close event of the switchboard. That event
fires even if they close from the X in the Access window.

--
I don't check the Email account attached
to this message. Send instead to...
RBrandt at Hunter dot com
Nov 13 '05 #18
WJA
Hi Rick. Several years ago when I first put this together that didn't
seem to work. I'm getting the username from another "startup" form.
Anyhow to cut a long story short, I've changed a couple of things
around and what you suggest works fine - as it should have if I'd done
it properly in the first place.

I can now allow the user to close the database window and hopefully
keep everyone happy!!

Thanks for your comments.

Nov 13 '05 #19
On Sun, 22 May 2005 16:36:39 +0200, "Arno R"
<ar***********@tiscali.nl> wrote:

<al********@hotmail.com> schreef in bericht news:11*********************@g14g2000cwa.googlegro ups.com...
This is a time sheet application and the users must complete it. I can
get the form to open as required but the client is requesting that the
users should not be able to 'opt out' of completing it in any way. My
form will not close but users have found that they can close it from
the task bar.
Is there any solution to this?
Alec


I don't think you can prevent users to close the app one way or another.
If you would find a registry-hack or so for the taskbar-rightclick-option, your users still could do a Ctrl-Alt-Delete I guess...
I agree with Chuck on this.

I bet your client wants something like: If there are records, they must be 'completed'.
You *can* require users to do things before you SAVE the record, so you can achieve what your client wants.


This IS the solution to your problem: The record must be completed or
it is not created at all. This way, the boss can simply issue an
edict: you MUST complete your time record. So if someone kills the
process before it is complete, what they entered is lost and they have
failed to heed the boss's edict.
Nov 13 '05 #20
Build a small form and in the Startup routine of your app open this
form acHidden and leave it open whilever your app is running.

In your code that closes the database, first set some flag to indicate
thatit is OK to close the database, eg a Public Variable or set a
control on the hidden form.
In the On UnLoad event of the hidden form, check to see if your flag
has been set, and if it hasn't Cancel the event. This will effectively
stop the form from closing and Access shutting down.
HiddenForm_UnLoad
If booOkToClose = False
Cancel=True
DoCmd.Openform "frmMenu"
End If
End Sub
Of course this (nor anything else) will handle three finger salutes or
hitting the power button.
"Lauren Wilson" <no****@private.com> wrote in message
news:s0********************************@4ax.com...
On Sun, 22 May 2005 16:36:39 +0200, "Arno R"
<ar***********@tiscali.nl> wrote:

<al********@hotmail.com> schreef in bericht
news:11*********************@g14g2000cwa.googleg roups.com...
This is a time sheet application and the users must complete it. I can
get the form to open as required but the client is requesting that the
users should not be able to 'opt out' of completing it in any way. My
form will not close but users have found that they can close it from
the task bar.
Is there any solution to this?
Alec


I don't think you can prevent users to close the app one way or another.
If you would find a registry-hack or so for the taskbar-rightclick-option,
your users still could do a Ctrl-Alt-Delete I guess...
I agree with Chuck on this.

I bet your client wants something like: If there are records, they must be
'completed'.
You *can* require users to do things before you SAVE the record, so you
can achieve what your client wants.


This IS the solution to your problem: The record must be completed or
it is not created at all. This way, the boss can simply issue an
edict: you MUST complete your time record. So if someone kills the
process before it is complete, what they entered is lost and they have
failed to heed the boss's edict.

Nov 13 '05 #21
MS

"David W. Fenton" <dX********@bway.net.invalid> wrote in message
news:Xn*********************************@24.168.12 8.86...
"MS" <Em***@Myemail.com> wrote in
news:wg*****************@news-server.bigpond.net.au:

"Wayne" <cq*******@volcanomail.com> wrote in message
news:11********************@f14g2000cwb.googlegrou ps.com...
Hi Alex. There are many reasons for forcing the user to close a
particular form before they can close the database. Mine is that
I run a "logon" query when a user opens the database and I
require a "logoff" query to be run before it is closed. If I
allow the user to close the database window the "logoff" query
does not run.

I'm no expert, but I found a method on this newgroup that works
well. It will stop the user closing the Access window by clicking
the "X" or by right clicking on your application's taskbar icon
and choosing "Close". They can still use the task manager to
close the app however.

Create a new module called "CloseAccess" or something similar and
paste the following code into it.

Option Compare Database
Option Explicit

Public pboolCloseAccess As Boolean

Function CloseDBFalse()
On Error Resume Next
pboolCloseAccess = False
End Function

Have a form open in hidden mode when you start your application.
In the form's "On Unload" event paste the following code:

If Not pboolCloseAccess Then Cancel = True

Close your database when required by placing:

"Docmd.Quit" in the "On Close" event of your main form or
switchboard.

Hope this helps.


Sounds like just what I've been looking for!


There's nothing innovative about the code above -- many of us have
been using that kind of thing for years. In the present discussion,
it wasn't relevant because it won't prohibit someone from force
quitting Access with the task manager, which is what I said on the
front end.

I still suggest that if you're forcing the app to stay open in order
to get user identity, then your app is very, very poorly designed.
Users should not have to indentify themselves before logging out.
You should either use Jet/Access security to keep track of users, or
pull the network login name. The user then won't have to worry about
it, and won't every be forced to jump through the hoops you're
constructing with code like the above that is basically a workaround
for an ill-chosen basic design.


I write databases (that work perfectly well, and save heaps of time) for the
people I work for.

Any "programming" I do is completely self taught. I'm no expert for sure.
But then most of the people who use the apps aren't computer literate
either - You ask them if they've "logged off", and they say "I can't". You
ask "why can't you?" And they say something like "the thing has
dispapeared". You ask "What thing?" They say "you know, the thing
that........"

And so on

I don't see a problem by requiring a user to close the application from a
user form, rather than by just clicking on the applications "X".

I use plenty of "commercial" software costing hundreds or thousands of
dollars that does just that! The "X" is actually greyed out!

I've designed quoting programs, job scheduling lists, complicated filing
systems etc in Access. The time theses things save at the office and
remotely on the field is very significant. We "interface" the Access quoting
apps, job list apps etc with our commercial accounting software. I have made
the office "paperles", with a single data entry point from quoting to
invoicing/despatch. Quite a feat IMO.

Ok, maybe things could been designed better in the first place. But many of
the apps are modified over time. They "evolve". Things get added, work
arounds have to be found. I'd love to start from scratch and redesign things
(I actually get a buzz "programming" and seeing the apps working) but all I
get a few hours a week to fix things at the bosses request. I'm not a
programmer contracted to a commercial software house earning hundreds of
dollars per hour ;-)

That's the beauty of Access. It can work at the level of professional
programmers who are able to charge customers big dollars for the programming
they do, but it can also be a very powerful, time saving tool for novices
who have taught themselves with nothing more than the help files and advice
from a news group.

Any way, Wayne, your solution works beautifully!!!!!
Nov 13 '05 #22
Thanks that works well.
Alex

"Wayne" <cq*******@volcanomail.com> wrote in message
news:11********************@f14g2000cwb.googlegrou ps.com...
Hi Alex. There are many reasons for forcing the user to close a
particular form before they can close the database. Mine is that I run
a "logon" query when a user opens the database and I require a "logoff"
query to be run before it is closed. If I allow the user to close the
database window the "logoff" query does not run.

I'm no expert, but I found a method on this newgroup that works well.
It will stop the user closing the Access window by clicking the "X" or
by right clicking on your application's taskbar icon and choosing
"Close". They can still use the task manager to close the app however.

Create a new module called "CloseAccess" or something similar and paste
the following code into it.

Option Compare Database
Option Explicit

Public pboolCloseAccess As Boolean

Function CloseDBFalse()
On Error Resume Next
pboolCloseAccess = False
End Function

Have a form open in hidden mode when you start your application. In
the form's "On Unload" event paste the following code:

If Not pboolCloseAccess Then Cancel = True

Close your database when required by placing:

"Docmd.Quit" in the "On Close" event of your main form or switchboard.

Hope this helps.

Nov 13 '05 #23

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

6
by: Miguelito Bain | last post by:
hi everybody- i have a form with 2 fields on it that i want the user to fill out before he or she can save the record, close the record, or move to the next record, etc... here's the code i...
6
by: Malcolm Webb | last post by:
I have experimented with the routine to prevent access from closing using the module authored by Dev Ashish to be found at "The Access web" site. Whilst this seems to work, it is not exactly what...
4
by: Daniel Walzenbach | last post by:
Hi, does anybody know the JavaScript the guys at Microsoft used in MS CRM to prevent people from closing a browser window and asking them (on the client) what they really want to do? If you...
9
by: Daniel Walzenbach | last post by:
Hi I am faced with the following problem: I have a page (let’s call this page page1.aspx) containing some TextBoxes and a hyperlink which opens another page (let’s call this page page2.aspx)...
2
by: kevininstructor | last post by:
I want to prevent a user from closing an application while doing critical operations. The following code (concept came from MSDN) works except for when the user attempts to terminate via "Task...
2
by: Lauren Wilson | last post by:
Hi folks, I believe I have seen this in this group in the past but my search comes up with nothing so far. I want to prevent our Access application from closing without some kind of...
4
by: tlyczko | last post by:
I have been looking on the NGs and I found this code to show if a subform has no records. I have this code in the MAIN form OnClose event: Private Sub btnClose_Click() '4/16/06 new code that...
3
by: sravan_reddy001 | last post by:
i want to prevent a form from closing.. to do this i want to handle the formClosing or FormClosed events. from here i want to prevent the form from closing. New instance of same form should...
7
by: Michiel Rapati-Kekkonen | last post by:
Hi, I would like my record to be saved only when my own close button (with all it's checks) is used. I made the winodws close button disappear, but you still can close using the right mouse...
0
marktang
by: marktang | last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
0
Oralloy
by: Oralloy | last post by:
Hello folks, I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>". The problem is that using the GNU compilers,...
0
jinu1996
by: jinu1996 | last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
0
agi2029
by: agi2029 | last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing,...
0
by: TSSRALBI | last post by:
Hello I'm a network technician in training and I need your help. I am currently learning how to create and manage the different types of VPNs and I have a question about LAN-to-LAN VPNs. The...
0
by: adsilva | last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
0
by: 6302768590 | last post by:
Hai team i want code for transfer the data from one system to another through IP address by using C# our system has to for every 5mins then we have to update the data what the data is updated ...
1
muto222
php
by: muto222 | last post by:
How can i add a mobile payment intergratation into php mysql website.
0
bsmnconsultancy
by: bsmnconsultancy | last post by:
In today's digital era, a well-designed website is crucial for businesses looking to succeed. Whether you're a small business owner or a large corporation in Toronto, having a strong online presence...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.