Discussion:
Trapping the X?
(too old to reply)
Salad
2010-09-15 04:58:16 UTC
Permalink
In a form I might have a BeforeUpdate event that does some final
validation before saving a record. Ex:
If IsNull(Me.LastName) then
msgbox "Please enter a last Name"
Me.lastname.setfocus
Cancel = True
Endif

I might have a command button called Exit where I can save the record
Me.Dirty = False
and trap the error if I attempt to close the form and not exit.

If I have nav buttons, it won't permit me to go to another record or a
new record until I've satisfied the error condition.

If I hit the X button in the upper right corner of the window to exit,
it runs the BeforeUpdate event, displays the error message, and closes
the form.

If it is a new record, the data is not saved. The form just closes.
There is no way to correct the error.

Do you employ any methodology to
1) not show the msgbox?
or
2) keep the form, with its data, open if in error? New or old rec?
or
3) use another event to trap/find errors?
Allen Browne
2010-09-15 11:53:29 UTC
Permalink
See:
Losing data when you close a form
at:
http://allenbrowne.com/bug-01.html

In any recent version of Access, you should get a message if you close the
form via the big X in the top right corner. If you use the Close method
(VBA) or action (macro), you will need to explicitly save first or you get
not notification.
--
Allen Browne - Microsoft MVP. Perth, Western Australia
Tips for Access users - http://allenbrowne.com/tips.html
Reply to group, rather than allenbrowne at mvps dot org.
Post by Salad
In a form I might have a BeforeUpdate event that does some final
If IsNull(Me.LastName) then
msgbox "Please enter a last Name"
Me.lastname.setfocus
Cancel = True
Endif
I might have a command button called Exit where I can save the record
Me.Dirty = False
and trap the error if I attempt to close the form and not exit.
If I have nav buttons, it won't permit me to go to another record or a new
record until I've satisfied the error condition.
If I hit the X button in the upper right corner of the window to exit, it
runs the BeforeUpdate event, displays the error message, and closes the
form.
If it is a new record, the data is not saved. The form just closes. There
is no way to correct the error.
Do you employ any methodology to
1) not show the msgbox?
or
2) keep the form, with its data, open if in error? New or old rec?
or
3) use another event to trap/find errors?
Salad
2010-09-15 16:57:05 UTC
Permalink
Post by Allen Browne
Losing data when you close a form
http://allenbrowne.com/bug-01.html
In any recent version of Access, you should get a message if you close
the form via the big X in the top right corner. If you use the Close
method (VBA) or action (macro), you will need to explicitly save first
or you get not notification.
Hi Allen:

Thanks for the link.

I decided to use a kludge. I created a TYPE array and when I enter the
B4Update I fill the array with the current data. If there is an error I
set a flag blnErr to True else False. In the unLoad event I check for
blnErr and if true I cancel and fill the fields with the array data. I
also have a Cancel button to Undo that permits the form to reset and
then a close (x) can work. A bit of typing work but it works. I wish
there were a way to trap the Close (X) button.

Amazing that its been around since A2. I'm sure more than a few have
complained.
David W. Fenton
2010-09-16 02:53:19 UTC
Permalink
Post by Salad
Do you employ any methodology to
1) not show the msgbox?
or
2) keep the form, with its data, open if in error? New or old
rec? or
3) use another event to trap/find errors?
4) eliminate the form's X and use my own CLOSE button (which can be
disguised to look like the normal X if you want to save space).
--
David W. Fenton http://www.dfenton.com/
contact via website only http://www.dfenton.com/DFA/
Salad
2010-09-16 03:25:37 UTC
Permalink
Post by David W. Fenton
Post by Salad
Do you employ any methodology to
1) not show the msgbox?
or
2) keep the form, with its data, open if in error? New or old
rec? or
3) use another event to trap/find errors?
4) eliminate the form's X and use my own CLOSE button (which can be
disguised to look like the normal X if you want to save space).
How do you do that? Get in the right hand corner of the title bar?


My kludge works but I'd hate to do that for a field packed form.
David W. Fenton
2010-09-16 22:43:08 UTC
Permalink
Post by Salad
Post by David W. Fenton
Post by Salad
Do you employ any methodology to
1) not show the msgbox?
or
2) keep the form, with its data, open if in error? New or old
rec? or
3) use another event to trap/find errors?
4) eliminate the form's X and use my own CLOSE button (which can
be disguised to look like the normal X if you want to save
space).
How do you do that? Get in the right hand corner of the title
bar?
No title bar. Like this:

Loading Image...

If you want to fake the title bar, you can do something like this:

Loading Image...
Post by Salad
My kludge works but I'd hate to do that for a field packed form.
Not sure what "that" is?
--
David W. Fenton http://www.dfenton.com/
contact via website only http://www.dfenton.com/DFA/
Salad
2010-09-16 23:12:36 UTC
Permalink
Post by David W. Fenton
Post by Salad
Post by David W. Fenton
Post by Salad
Do you employ any methodology to
1) not show the msgbox?
or
2) keep the form, with its data, open if in error? New or old
rec? or
3) use another event to trap/find errors?
4) eliminate the form's X and use my own CLOSE button (which can
be disguised to look like the normal X if you want to save
space).
How do you do that? Get in the right hand corner of the title
bar?
http://dfenton.com/DFA/Splash/bellevue.jpg
http://dfenton.com/DFA/examples/assignment.gif
Very cool.
Post by David W. Fenton
Post by Salad
My kludge works but I'd hate to do that for a field packed form.
Not sure what "that" is?
I described what I did in a prior post; created an array, stored the
data in the B4Update, and OnUnload stopped it if there were an error and
reloaded the data. Your method has much better control.
The Frog
2010-09-17 07:56:05 UTC
Permalink
I do exactly the same thing as David. I remove the title bar
completely, and I also remove the controls from forms and create my
own. It was the only way I could guarantee control over the process.
Has worked fine for years.

The Frog
Salad
2010-09-17 14:21:43 UTC
Permalink
Post by The Frog
I do exactly the same thing as David. I remove the title bar
completely, and I also remove the controls from forms and create my
own. It was the only way I could guarantee control over the process.
Has worked fine for years.
The Frog
You guys think out of the box. :)
David W. Fenton
2010-09-17 21:33:16 UTC
Permalink
Post by Salad
Post by The Frog
I do exactly the same thing as David. I remove the title bar
completely, and I also remove the controls from forms and create
my own. It was the only way I could guarantee control over the
process. Has worked fine for years.
You guys think out of the box. :)
Well, the second of my examples was really entirely driven by
cosmetic issues -- they wanted each main form to have a different,
as each represented one of the major areas of the app. Here are the
four main forms:

Loading Image...

http://dfenton.com/DFA/examples/assignment.gif

Loading Image...

They didn't want to have the standard Windows title bar there
because they wanted the whole form to be coordinated with the color
scheme.

I thought it looked so nice that I didn't rebel. And that was back
in the day when I was more pliable in regard to things like this...
--
David W. Fenton http://www.dfenton.com/
contact via website only http://www.dfenton.com/DFA/
Salad
2010-09-18 09:37:55 UTC
Permalink
Post by The Frog
I do exactly the same thing as David. I remove the title bar
completely, and I also remove the controls from forms and create my
own. It was the only way I could guarantee control over the process.
Has worked fine for years.
The Frog
In David's examples he has only the X box. Is yours the same as well?
If you have a form and you minimize it the controls don't track as well.
Do you have code in the Activate event to move the buttons as well?
David W. Fenton
2010-09-18 20:18:51 UTC
Permalink
Post by Salad
Post by The Frog
I do exactly the same thing as David. I remove the title bar
completely, and I also remove the controls from forms and create
my own. It was the only way I could guarantee control over the
process. Has worked fine for years.
In David's examples he has only the X box. Is yours the same as
well? If you have a form and you minimize it the controls don't
track as well.
Do you have code in the Activate event to move the buttons as well?
My observation of users is that they have no desire whatsoever to
minimize their forms.

The only thing I'm wondering about is if in your case you'd need to
trap Ctrl-F4. I can't recall if it works for forms without title
bars or not.
--
David W. Fenton http://www.dfenton.com/
contact via website only http://www.dfenton.com/DFA/
The Frog
2010-09-20 09:23:16 UTC
Permalink
Hi Salad,

I keep my forms modal (mostly) and completely eliminate the 'X' so to
speak. I place a substitute 'X' - which is really just a command
button in the appropriate location. I have done sometimes the same
with a minimize but never worked out how to re-maximise it, so in the
end I used modal forms. The user is either working on the form that is
open, or they are not. If I need a type of switching between forms
then I use a multitab type approach with all the possible 'things' a
user could want on a single form (so to speak).

I did see a nice multitab form that allowed the creation of new tabs
on the fly, as well as the closing of those tabs, similar to a web
browser I suppose. I have not tried to replicate the functionality as
none of the apps I work with / design have required it. If I needed
greater complexity and / or flexibility I would probably head this way
as it was extremely neat and effective. If I get time I might have a
go at replicating the functionality, but I am guessing it would not be
straight forward, and would probably be meta-data driven (ie/ you need
some sort of descriptor of what goes where on a form and the functions
it requires etc...., then the forms own code could add a tab and build
the appropriate form.) Nice, but seems like a heap of work if you dont
actually need it. From an academic point of view I would love to know
how they actually did it though.

Cheers

The Frog
Salad
2010-09-20 17:10:20 UTC
Permalink
Post by The Frog
Hi Salad,
I keep my forms modal (mostly) and completely eliminate the 'X' so to
speak. I place a substitute 'X' - which is really just a command
button in the appropriate location. I have done sometimes the same
with a minimize but never worked out how to re-maximise it, so in the
end I used modal forms. The user is either working on the form that is
open, or they are not. If I need a type of switching between forms
then I use a multitab type approach with all the possible 'things' a
user could want on a single form (so to speak).
I did see a nice multitab form that allowed the creation of new tabs
on the fly, as well as the closing of those tabs, similar to a web
browser I suppose. I have not tried to replicate the functionality as
none of the apps I work with / design have required it. If I needed
greater complexity and / or flexibility I would probably head this way
as it was extremely neat and effective. If I get time I might have a
go at replicating the functionality, but I am guessing it would not be
straight forward, and would probably be meta-data driven (ie/ you need
some sort of descriptor of what goes where on a form and the functions
it requires etc...., then the forms own code could add a tab and build
the appropriate form.) Nice, but seems like a heap of work if you dont
actually need it. From an academic point of view I would love to know
how they actually did it though.
Cheers
The Frog
Kinda what I thought.

It'd be nice if MS set a flag when the "X" is pressed. Then a person
could let the op knop that data won't be saved if validation checks
don't pass.
James A. Fortune
2010-09-21 01:53:47 UTC
Permalink
Post by Salad
Post by The Frog
Hi Salad,
I keep my forms modal (mostly) and completely eliminate the 'X' so to
speak. I place a substitute 'X' - which is really just a command
button in the appropriate location. I have done sometimes the same
with a minimize but never worked out how to re-maximise it, so in the
end I used modal forms. The user is either working on the form that is
open, or they are not. If I need a type of switching between forms
then I use a multitab type approach with all the possible 'things' a
user could want on a single form (so to speak).
I did see a nice multitab form that allowed the creation of new tabs
on the fly, as well as the closing of those tabs, similar to a web
browser I suppose. I have not tried to replicate the functionality as
none of the apps I work with / design have required it. If I needed
greater complexity and / or flexibility I would probably head this way
as it was extremely neat and effective. If I get time I might have a
go at replicating the functionality, but I am guessing it would not be
straight forward, and would probably be meta-data driven (ie/ you need
some sort of descriptor of what goes where on a form and the functions
it requires etc...., then the forms own code could add a tab and build
the appropriate form.) Nice, but seems like a heap of work if you dont
actually need it. From an academic point of view I would love to know
how they actually did it though.
Cheers
The Frog
Kinda what I thought.
It'd be nice if MS set a flag when the "X" is pressed.  Then a person
could let the op knop that data won't be saved if validation checks
don't pass.
Maybe I'm missing something here, but if the Exit command button
simply closes the form, why can't the form's unload event take care of
either way of closing the form and give the user the opportunity to
save changes? A simple test I tried that traps a variant Response
variable for a MsgBox in the Unload event suggests that the user can
choose to have the changes saved.

J. A. Fortune
***@FortuneJames.com
Salad
2010-09-21 03:57:28 UTC
Permalink
Post by James A. Fortune
Post by Salad
Post by The Frog
Hi Salad,
I keep my forms modal (mostly) and completely eliminate the 'X' so to
speak. I place a substitute 'X' - which is really just a command
button in the appropriate location. I have done sometimes the same
with a minimize but never worked out how to re-maximise it, so in the
end I used modal forms. The user is either working on the form that is
open, or they are not. If I need a type of switching between forms
then I use a multitab type approach with all the possible 'things' a
user could want on a single form (so to speak).
I did see a nice multitab form that allowed the creation of new tabs
on the fly, as well as the closing of those tabs, similar to a web
browser I suppose. I have not tried to replicate the functionality as
none of the apps I work with / design have required it. If I needed
greater complexity and / or flexibility I would probably head this way
as it was extremely neat and effective. If I get time I might have a
go at replicating the functionality, but I am guessing it would not be
straight forward, and would probably be meta-data driven (ie/ you need
some sort of descriptor of what goes where on a form and the functions
it requires etc...., then the forms own code could add a tab and build
the appropriate form.) Nice, but seems like a heap of work if you dont
actually need it. From an academic point of view I would love to know
how they actually did it though.
Cheers
The Frog
Kinda what I thought.
It'd be nice if MS set a flag when the "X" is pressed. Then a person
could let the op knop that data won't be saved if validation checks
don't pass.
Maybe I'm missing something here, but if the Exit command button
simply closes the form, why can't the form's unload event take care of
either way of closing the form and give the user the opportunity to
save changes? A simple test I tried that traps a variant Response
variable for a MsgBox in the Unload event suggests that the user can
choose to have the changes saved.
New or old rec?

Cancel = True on a saved rec works ok in the Unload. (I'm not going to
test to see if it saves the modified data or just the old if Cancel =
True) But on a new rec, if it displays an error message as in
B4_Update event
If IsNull(FirstName) then
msgbox "Supply a first name"
cancel = True
blnErr = True
Me.FirstName.setfocus
Endif
then when it hits the Unload event
IF blnErr then Cancel = True
the new data is wiped out if the (X) is used.

It seems kinda of stupid to even display the error message if the data
is going to be wiped out. And if you don't have Cancel = True in the
Unload event, the Cancel in the B4Update is ignored. Where's the benefit?

It would be one thing if the only thing you ever did was use an command
exit button. But if you have navigation buttons you can't trap them
(know that they were used to move to another record) or the Exit button.
With the Nav buttons they at least recognize the B4Update and keep
the data, not the (X) button.

If you have a method to hit the (X) button in the title bar, display any
error messages in the B4Update event and remain open and keep the data
let me know.
Post by James A. Fortune
J. A. Fortune
James A. Fortune
2010-09-21 19:44:19 UTC
Permalink
Post by Salad
New or old rec?
Cancel = True on a saved rec works ok in the Unload.  (I'm not going to
test to see if it saves the modified data or just the old if Cancel =
True)  But on a new rec, if it displays an error message as in
    B4_Update event
        If IsNull(FirstName) then
                msgbox "Supply a first name"
                cancel = True
                blnErr = True
                Me.FirstName.setfocus
        Endif
then when it hits the Unload event
        IF blnErr then Cancel = True
the new data is wiped out if the (X) is used.
It seems kinda of stupid to even display the error message if the data
is going to be wiped out.  And if you don't have Cancel = True in the
Unload event, the Cancel in the B4Update is ignored.  Where's the benefit?
It would be one thing if the only thing you ever did was use an command
exit button.  But if you have navigation buttons you can't trap them
(know that they were used to move to another record) or the Exit button.
    With the Nav buttons they at least recognize the B4Update and keep
the data, not the (X) button.
If you have a method to hit the (X) button in the title bar, display any
error messages in the B4Update event and remain open and keep the data
let me know.
Thanks, Salad. I see where you're coming from now. I'll play around
with it a bit to see what I can discover.

James A. Fortune
***@FortuneJames.com

Continue reading on narkive:
Loading...