By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
435,583 Members | 3,411 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 435,583 IT Pros & Developers. It's quick & easy.

Can I control how user exits access?

P: n/a
Hi

I have a problem with a database where certain users are closing access (by
clicking on the X in top right-hand corner) instead of using a command
button before they fill in all relevant fields.

Q. Is there a way of not allowing them to exist access using the this way
and use the command button?

Thanks in Advance
David Sullivan
Nov 13 '05 #1
Share this Question
Share on Google+
6 Replies


P: n/a
HJ
Yes, you can. On a form you can use the Unload event to prevent it from
closing, unless you want it to. I use it myself on a form that remains open
at all times and that can only be closed with a command button.

Private Sub Form_Unload(Cancel As Integer)

.... do anything...

Cancel = True

.... do anything...

End Sub

Regards,

HJ

"David Sullivan" <da******@indigo.ie> wrote in message
news:_V*******************@news.indigo.ie...
Hi

I have a problem with a database where certain users are closing access (by clicking on the X in top right-hand corner) instead of using a command
button before they fill in all relevant fields.

Q. Is there a way of not allowing them to exist access using the this way
and use the command button?

Thanks in Advance
David Sullivan

Nov 13 '05 #2

P: n/a
HJ wrote:
Yes, you can. On a form you can use the Unload event to prevent it from
closing, unless you want it to. I use it myself on a form that remains open
at all times and that can only be closed with a command button.

Private Sub Form_Unload(Cancel As Integer)

... do anything...

Cancel = True

... do anything...

End Sub

Regards,

HJ


It works for a record that exists. It will not save new recs. It's too
bad MS didn't put in a trap that could exist prior to the BeforeUpdate
that could trap for it.
Nov 13 '05 #3

P: n/a
HJ

"Salad" <oi*@vinegar.com> wrote in message
news:GW****************@newsread3.news.pas.earthli nk.net...

It works for a record that exists. It will not save new recs. It's too
bad MS didn't put in a trap that could exist prior to the BeforeUpdate
that could trap for it.


It does save new records, because when you close the form (and the
application) the newly entered data is saved; Access has been designed that
way.

But you may need to program some record handling for that Unload event,
based on your needs. E.g. by using a global or public variable that is set
when you edit a record, or by having the user enter a minimum set of data in
the new record (and check that with a procedure that results in True or
False), etc.
Nov 13 '05 #4

P: n/a
HJ wrote:
"Salad" <oi*@vinegar.com> wrote in message
news:GW****************@newsread3.news.pas.earthli nk.net...
It works for a record that exists. It will not save new recs. It's too
bad MS didn't put in a trap that could exist prior to the BeforeUpdate
that could trap for it.

It does save new records, because when you close the form (and the
application) the newly entered data is saved; Access has been designed that
way.

But you may need to program some record handling for that Unload event,
based on your needs. E.g. by using a global or public variable that is set
when you edit a record, or by having the user enter a minimum set of data in
the new record (and check that with a procedure that results in True or
False), etc.


Hmmmm....I know there is a big flaw, as far as I'm concerned, with the
Unload event. It's possible that the flaw is that the form's
BeforeUpdate event can't be canceled. Something like that. It's a pain
in the butt and there is no known solution for it that I'm aware of. It
might be OK if there is no before/after update event for the form.

I think its BeforeUpdate. If you attempt to cancel because an error
exists or some field is missing data or something like that...it might
be with a new record...the unload cancels and all data for the new
record is lost. Maybe it does the same for editting a current record.

It's almost as if MS forgot about the BeforeUpdate event.

Nov 13 '05 #5

P: n/a
David Sullivan wrote:
I have a problem with a database where certain users are closing access (by
clicking on the X in top right-hand corner) instead of using a command
button before they fill in all relevant fields.


Here's one method.

Create a form and call it something simple - I use "frmV" and often use
it to store variables in controls instead of relying on global
variables. In the unload event of this form, have the procedures that
you want to make sure happen when the database app is closed. The trick
is, you want this form to open *hidden* when the database is opened.

There are a couple of ways to accomplish this. I will sometimes have a
splash form that appears on opening of the mdb or simply a starting form
with cancel = true in the on open event.

If you use the latter, put in a

DoCmd.OpenForm "frmV", acNormal, , , , acHidden

and then your cancel = true. If you use a splash form that your users
bring up whenever they click on About This App on a menu item or
something, you can check to see if frm HIdden is open in the on open
event of the form (air code):

Private Sub Form_Open(Cancel As Integer)

dim f as Access.form
dim booFound as boolean

boofound = false

for each f in access.forms

if f.name = "frmV" then 'frmOpen is found and is already open

boofound = true

exit for

end if

Next

if boofound = false then DoCmd.OpenForm "frmV", acNormal, , , , acHidden

End Sub

--
Tim
^o<
/#) "Burp-beep, burp-beep, burp-beep?" - Quaker Jake
/^^ "What's UP, Dittoooooo?" - Ditto
Nov 13 '05 #6

P: n/a
Correction:

Tim Marshall wrote:
if f.name = "frmV" then 'frmOpen is found and is already open


Should be:

if f.name = "frmV" then 'frmV is found and is already open

--
Tim
^o<
/#) "Burp-beep, burp-beep, burp-beep?" - Quaker Jake
/^^ "What's UP, Dittoooooo?" - Ditto
Nov 13 '05 #7

This discussion thread is closed

Replies have been disabled for this discussion.