setting Cancel in BeforeUpdate fired from closing form problem

hey guys,

here's an empty database with a form to demonstrate this problem.BeforeUpdateCancel.mdb

when i press the "x" at the top right of the form to close the form, the beforeupdate event fires.

in the beforeupdate event i set the Cancel variable to True --> because i want to cancel the update.

the result of this is that this message box pops up.

you can't save this record at this time
goal: i want to cancel the form update when the user clicks the "x" at the top right of the form.

question --> 1) why is this msgbox popping up? could yall give me a technical insight into the mechanisms of it?
2) how do i achieve my goal of canceling the form update when the user clicks the "x"?

P.S. i found the solution is to only use the Me.Undo line without the Cancel = True --> and i do understand the difference between Undo and Cancel, but i just can't understand why the Cancel = True when the form is closing causes a problem? definitely i suspect that i'm "tinkering" around with the inner workings of Access cause the form is closing with presumably an automatic save and i am asking it to cancel the save

here are 2 great posts which helped me quite a bit but just shy of the final problem i've posted here
a) from EE PatHartman really helped me a lot on this but using her code somehow it's not working i'm not sure why http://www.experts-exchange.com/Microsoft/Development/MS_Access/Q_28259652.html
b) another developer facing the same problem who resorted to quite a long way of doing things i feel http://bytes.com/topic/access/answers/647206-cancelling-record-update-beforeupdate-event
developingprogrammerAsked:
Who is Participating?

[Webinar] Streamline your web hosting managementRegister Today

x
 
Scott McDaniel (Microsoft Access MVP - EE MVE )Connect With a Mentor Infotrakker SoftwareCommented:
Cancel = True will cancel the Update event, and Access won't be able to close the form (since it's dirty, and access won't close a dirty form without saving). If you want to NOT save changes, then just put Me.Undo, and let it go at that.

However, I think you need to further define the work flow of the form. If a user fills in data, and they want to save it, exactly how are they supposed to do that if the BU event is always undoing their work? In general, most users would expect the form to save the data and close when the explicitly ask it to do so - so why would you go against those expectations?
0
 
clarkscottConnect With a Mentor Commented:
I suppress the X top right corner and make my users click a CLOSE button.
You can add any data validation you need in a function and call the function before closing the form in code.

Most efficient way... no issues with "X's", or trying to figure out what event to "cancel" ....

Scott C
0
 
developingprogrammerAuthor Commented:
thanks LSMConsulting as always! = )

i have a variable which says whether to save or not in the BU event and so that helps define the workflow. i think your sentence

Cancel = True will cancel the Update event, and Access won't be able to close the form (since it's dirty, and access won't close a dirty form without saving)

beautifully summarises it = )

thanks Scott too! i guess i'm trying to challenge myself to fit into users expectations of having a x button on the top right (because they are trained by windows to expect that already). but thanks still for your tip! definitely helps! = )
0
 
clarkscottCommented:
Further.... When you build "system" apps, you must control it.  To do so most efficiently, you must bottleneck.  One way in - one way out.  If there's no exception, then there is no multiple methods for dealing with it.  It's really as simple as that.

I usually put a black-filled box behind my "close buttons".  This makes it very easy for users to see, and recognize, exactly how to close my forms.

PS.  I put a red-filled box behind my "Delete" options - same reason.

Thanks for the points and have a great Holiday Season !!

Scott C.
0
All Courses

From novice to tech pro — start learning today.