Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.databases.ms-access > #9179 > unrolled thread

Need to cancel the update to a bound form if edits fail (Access 2010)

Back to article view | Back to comp.databases.ms-access

Contents

  Need to cancel the update to a bound form if edits fail (Access 2010) PW <emailaddyinsig@ifIremember.com> - 2014-03-22 15:30 -0600
    Re: Need to cancel the update to a bound form if edits fail (Access 2010) Patrick Finucane <patrickfinucanetx@gmail.com> - 2014-03-24 07:53 -0700
      Re: Need to cancel the update to a bound form if edits fail (Access 2010) PW <emailaddyinsig@ifIremember.com> - 2014-03-24 10:22 -0600
        Re: Need to cancel the update to a bound form if edits fail (Access 2010) "Access Developer" <accdevel@gmail.com> - 2014-03-24 12:47 -0500
          Re: Need to cancel the update to a bound form if edits fail (Access 2010) "Phil" <phil@stantonfamily.co.uk> - 2014-03-24 23:00 +0000
            Re: Need to cancel the update to a bound form if edits fail (Access 2010) Ulrich Möller <knobbi38@usenet.arcornews.de> - 2014-03-25 04:31 +0100
              Re: Need to cancel the update to a bound form if edits fail (Access 2010) "Phil" <phil@stantonfamily.co.uk> - 2014-03-25 09:42 +0000
              Re: Need to cancel the update to a bound form if edits fail (Access 2010) PW <emailaddyinsig@ifIremember.com> - 2014-04-03 21:21 -0600
            Re: Need to cancel the update to a bound form if edits fail (Access 2010) "Access Developer" <accdevel@gmail.com> - 2014-03-25 11:50 -0500
              Re: Need to cancel the update to a bound form if edits fail (Access 2010) Ulrich Möller <knobbi38@usenet.arcornews.de> - 2014-03-25 20:23 +0100
                Re: Need to cancel the update to a bound form if edits fail (Access 2010) "Access Developer" <accdevel@gmail.com> - 2014-03-26 14:46 -0500
              Re: Need to cancel the update to a bound form if edits fail (Access 2010) "Phil" <phil@stantonfamily.co.uk> - 2014-03-26 20:12 +0000
      Re: Need to cancel the update to a bound form if edits fail (Access 2010) PW <emailaddyinsig@ifIremember.com> - 2014-03-24 10:57 -0600
        Re: Need to cancel the update to a bound form if edits fail (Access 2010) Patrick Finucane <patrickfinucanetx@gmail.com> - 2014-03-24 10:21 -0700

#9179 — Need to cancel the update to a bound form if edits fail (Access 2010)

Hi,

And stay on the form if the user wants to, without blanking out the
record.

So if a required field was not filled out, I have a messagebox asking
the user if they want to exit the form without saving the record.  If
they answer No, then I want to still have the form loaded and give
them a chance to enter in the required information.  If they answer
yes, then I want to exit the form without Access automatically saving
the record.

I do not want to have to make all controls unbound and then have to
write code to handle this (although I could, but it would take alot of
time on some of these forms.  I want to be consistent.).

Does anyone have a routine to do this?

-paulw

[toc] | [next] | [standalone]

#9182

On Saturday, March 22, 2014 4:30:49 PM UTC-5, PW wrote:
> Hi, And stay on the form if the user wants to, without blanking out the record. So if a required field was not filled out, I have a messagebox asking the user if they want to exit the form without saving the record. If they answer No, then I want to still have the form loaded and give them a chance to enter in the required information. If they answer yes, then I want to exit the form without Access automatically saving the record. I do not want to have to make all controls unbound and then have to write code to handle this (although I could, but it would take alot of time on some of these forms. I want to be consistent.). Does anyone have a routine to do this? -paulw

If msgbox("Exit form?,vbYesNo,"Confirm") = vbYes then
  Me.Undo
Else
  Me.SomeField.SetFocus
Endif

[toc] | [prev] | [next] | [standalone]

#9183

On Mon, 24 Mar 2014 07:53:05 -0700 (PDT), Patrick Finucane
<patrickfinucanetx@gmail.com> wrote:

>On Saturday, March 22, 2014 4:30:49 PM UTC-5, PW wrote:
>> Hi, And stay on the form if the user wants to, without blanking out the record. So if a required field was not filled out, I have a messagebox asking the user if they want to exit the form without saving the record. If they answer No, then I want to still have the form loaded and give them a chance to enter in the required information. If they answer yes, then I want to exit the form without Access automatically saving the record. I do not want to have to make all controls unbound and then have to write code to handle this (although I could, but it would take alot of time on some of these forms. I want to be consistent.). Does anyone have a routine to do this? -paulw
>
>If msgbox("Exit form?,vbYesNo,"Confirm") = vbYes then
>  Me.Undo
>Else
>  Me.SomeField.SetFocus
>Endif

I was doing that and the record was getting saved w/o passing edits.
Put the Undo in the BeforeUpdate event?  And isn't that just for new
records?

What if the user blanks out a required field in an existing record?

By the way, I saw many examples from a search and they all do me.Undo,
and then Cancel=True.  Cancel=True would not allow me to exit the form
using the X/Close button.  I don't even know what it is supposed to
do.

Thanks Patrick

-paulw

[toc] | [prev] | [next] | [standalone]

#9186

"PW" <emailaddyinsig@ifIremember.com> wrote

 > I was doing that and the record was
 > getting saved w/o passing edits.
 > Put the Undo in the BeforeUpdate
 > event?

There are several things that can cause the record to be updated, to wit, 
moving focus to a Subform control or an explicit save via keypress or code 
action, and moving off the current record to another record, or closing the 
form. You can't stop an Update in the After Update event because, of course, 
the update has already occurred. If you want to cancel, you must do so 
before the update occurs.

 > And isn't that just for new
 > records?

No, Before Update event applies to all records being written. Before / After 
Insert applies only to new records.

 > What if the user blanks out a
 > required field in an existing record?

As best I remember, if you defined the field as required in the table 
definition, the database engine will enforce that, and will not write a 
record without the field.

 > By the way, I saw many examples
 > from a search and they all do me.Undo,
 > and then Cancel=True.  Cancel=True
 > would not allow me to exit the form
 > using the X/Close button.  I don't even
 > know what it is supposed to do.

Cancel = True does exactly what it says... it cancels writing / updating the 
record.  I believe it does, by design, return you to the form.  If there's 
still data in the form, and there's a problem that prevents the record being 
written, closing the form will not work.

   Larry Linson
     Microsoft Access MVP
     Co-Author, Microsoft Access Small Business Solutions, pub. by Wiley 

[toc] | [prev] | [next] | [standalone]

#9187

On 24/03/2014 17:47:36, "Access Developer" wrote:
> "PW" <emailaddyinsig@ifIremember.com> wrote
> 
> > I was doing that and the record was
> > getting saved w/o passing edits.
> > Put the Undo in the BeforeUpdate
> > event?
> 
> There are several things that can cause the record to be updated, to wit,
> moving focus to a Subform control or an explicit save via keypress or code
> action, and moving off the current record to another record, or closing
> the form. You can't stop an Update in the After Update event because, of
> course, the update has already occurred. If you want to cancel, you must
> do so before the update occurs.
> 
> > And isn't that just for new
> > records?
> 
> No, Before Update event applies to all records being written. Before /
> After Insert applies only to new records.
> 
> > What if the user blanks out a
> > required field in an existing record?
> 
> As best I remember, if you defined the field as required in the table
> definition, the database engine will enforce that, and will not write a
> record without the field.
> 
> > By the way, I saw many examples
> > from a search and they all do me.Undo,
> > and then Cancel=True.  Cancel=True
> > would not allow me to exit the form
> > using the X/Close button.  I don't even
> > know what it is supposed to do.
> 
> Cancel = True does exactly what it says... it cancels writing / updating
> the record. I believe it does, by design, return you to the form. If
> there's still data in the form, and there's a problem that prevents the
> record being written, closing the form will not work.
> 
> Larry Linson
> Microsoft Access MVP
> Co-Author, Microsoft Access Small Business Solutions, pub. by Wiley
> 
> 

This is a routine to check a post code has been entered

Private Sub Form_BeforeUpdate(Cancel As Integer)
    
    If CheckPostCode = False Then
        DoCmd.CancelEvent
    End If
    
End Sub

Function CheckPostCode() As Boolean

    If Nz(PostCode) = "" Then
If If MsgBox("You have not entered the post code, Do you want to correct
this?", vbQuestion + vbYesNo) = vbNo Then             Me.Undo
            MsgBox "All changes have been discarded"
        Else
            PostCode.SetFocus
        End If
    Else
        CheckPostCode = True
    End If
    
End Function

It works OK, but for some reason if you close the form there is an error
message to say it can't save the record (which is unchanged anyway)

Phil

---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com

[toc] | [prev] | [next] | [standalone]

#9189

Am 25.03.2014 00:00, schrieb Phil:
> On 24/03/2014 17:47:36, "Access Developer" wrote:
>> "PW" <emailaddyinsig@ifIremember.com> wrote
>>
>>> I was doing that and the record was
>>> getting saved w/o passing edits.
>>> Put the Undo in the BeforeUpdate
>>> event?
>> There are several things that can cause the record to be updated, to wit,
>> moving focus to a Subform control or an explicit save via keypress or code
>> action, and moving off the current record to another record, or closing
>> the form. You can't stop an Update in the After Update event because, of
>> course, the update has already occurred. If you want to cancel, you must
>> do so before the update occurs.
>>
>>> And isn't that just for new
>>> records?
>> No, Before Update event applies to all records being written. Before /
>> After Insert applies only to new records.
>>
>>> What if the user blanks out a
>>> required field in an existing record?
>> As best I remember, if you defined the field as required in the table
>> definition, the database engine will enforce that, and will not write a
>> record without the field.
>>
>>> By the way, I saw many examples
>>> from a search and they all do me.Undo,
>>> and then Cancel=True.  Cancel=True
>>> would not allow me to exit the form
>>> using the X/Close button.  I don't even
>>> know what it is supposed to do.
>> Cancel = True does exactly what it says... it cancels writing / updating
>> the record. I believe it does, by design, return you to the form. If
>> there's still data in the form, and there's a problem that prevents the
>> record being written, closing the form will not work.
>>
>> Larry Linson
>> Microsoft Access MVP
>> Co-Author, Microsoft Access Small Business Solutions, pub. by Wiley
>>
>>
> This is a routine to check a post code has been entered
>
> Private Sub Form_BeforeUpdate(Cancel As Integer)
>      
>      If CheckPostCode = False Then
>          DoCmd.CancelEvent
>      End If
>      
> End Sub
>
> Function CheckPostCode() As Boolean
>
>      If Nz(PostCode) = "" Then
> If If MsgBox("You have not entered the post code, Do you want to correct
> this?", vbQuestion + vbYesNo) = vbNo Then             Me.Undo
>              MsgBox "All changes have been discarded"
>          Else
>              PostCode.SetFocus
>          End If
>      Else
>          CheckPostCode = True
>      End If
>      
> End Function
>
> It works OK, but for some reason if you close the form there is an error
> message to say it can't save the record (which is unchanged anyway)
>
> Phil
>
> ---
> This email is free from viruses and malware because avast! Antivirus protection is active.
> http://www.avast.com
>
Hi Phil,

in the beforeupdate event you can suppress any updates of the database 
table with the cancel variable set to true or running the macro 
docmd.cancelevent but your current record of the form will still be 
dirty! Just make a undo on the edited form or control to discard all 
changes.  After that, you should be able to close your form, but ...
If you are currently in a new record and have required fields in the 
table then it is still not possible to save the record, because of the 
validation rules. Try to check/debug the DataErr in the form error event 
to get an idea what is preventing you from closing the form. Typical 
error codes are 2169, 3022, 3314. You should always handle this codes in 
the form error event too.

Take a notice on the form properties "newrecord" and "dirty" in the 
online help.

If you use cancel in the beforeupdate event you also have to ensure that 
the form.dirty and form.newrecord properties are both false when you 
want to close the form otherwise you will trap in a classic loop.

Ulrich

[toc] | [prev] | [next] | [standalone]

#9190

On 25/03/2014 03:31:32, Ulrich Möller wrote:
> Am 25.03.2014 00:00, schrieb Phil:
>> On 24/03/2014 17:47:36, "Access Developer" wrote:
>>> "PW" <emailaddyinsig@ifIremember.com> wrote
>>>
>>>> I was doing that and the record was
>>>> getting saved w/o passing edits.
>>>> Put the Undo in the BeforeUpdate
>>>> event?
>>> There are several things that can cause the record to be updated, to wit,
>>> moving focus to a Subform control or an explicit save via keypress or code
>>> action, and moving off the current record to another record, or closing
>>> the form. You can't stop an Update in the After Update event because, of
>>> course, the update has already occurred. If you want to cancel, you must
>>> do so before the update occurs.
>>>
>>>> And isn't that just for new
>>>> records?
>>> No, Before Update event applies to all records being written. Before /
>>> After Insert applies only to new records.
>>>
>>>> What if the user blanks out a
>>>> required field in an existing record?
>>> As best I remember, if you defined the field as required in the table
>>> definition, the database engine will enforce that, and will not write a
>>> record without the field.
>>>
>>>> By the way, I saw many examples
>>>> from a search and they all do me.Undo,
>>>> and then Cancel=True.  Cancel=True
>>>> would not allow me to exit the form
>>>> using the X/Close button.  I don't even
>>>> know what it is supposed to do.
>>> Cancel = True does exactly what it says... it cancels writing / updating
>>> the record. I believe it does, by design, return you to the form. If
>>> there's still data in the form, and there's a problem that prevents the
>>> record being written, closing the form will not work.
>>>
>>> Larry Linson
>>> Microsoft Access MVP
>>> Co-Author, Microsoft Access Small Business Solutions, pub. by Wiley
>>>
>>>
>> This is a routine to check a post code has been entered
>>
>> Private Sub Form_BeforeUpdate(Cancel As Integer)
>>
>>      If CheckPostCode = False Then
>>          DoCmd.CancelEvent
>>      End If
>>
>> End Sub
>>
>> Function CheckPostCode() As Boolean
>>
>>      If Nz(PostCode) = "" Then
>> If If MsgBox("You have not entered the post code, Do you want to correct
>> this?", vbQuestion + vbYesNo) = vbNo Then             Me.Undo
>>              MsgBox "All changes have been discarded"
>>          Else
>>              PostCode.SetFocus
>>          End If
>>      Else
>>          CheckPostCode = True
>>      End If
>>
>> End Function
>>
>> It works OK, but for some reason if you close the form there is an error
>> message to say it can't save the record (which is unchanged anyway)
>>
>> Phil
>>
>> ---
>> This email is free from viruses and malware because avast! Antivirus protection is active.
>> http://www.avast.com
>>
> Hi Phil,
> 
> in the beforeupdate event you can suppress any updates of the database
> table with the cancel variable set to true or running the macro
> docmd.cancelevent but your current record of the form will still be
> dirty! Just make a undo on the edited form or control to discard all
> changes.  After that, you should be able to close your form, but ...
> If you are currently in a new record and have required fields in the
> table then it is still not possible to save the record, because of the
> validation rules. Try to check/debug the DataErr in the form error event
> to get an idea what is preventing you from closing the form. Typical
> error codes are 2169, 3022, 3314. You should always handle this codes in
> the form error event too.
> 
> Take a notice on the form properties "newrecord" and "dirty" in the
> online help.
> 
> If you use cancel in the beforeupdate event you also have to ensure that
> the form.dirty and form.newrecord properties are both false when you
> want to close the form otherwise you will trap in a classic loop.
> 
> Ulrich
> 
> 
> 

Spot on as ever, Ulrich

Added Private Sub Form_Error(DataErr As Integer, Response As Integer)

    Select Case DataErr
    Case 2169
        Response = acDataErrContinue
    Case Else
        Response = acDataErrDisplay
    End Select
    
End Sub

which cures the problem.
So that, with a bit of luck answers Paul's original question.

Phil

---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com

[toc] | [prev] | [next] | [standalone]

#9240

On Tue, 25 Mar 2014 04:31:36 +0100, Ulrich Möller
<knobbi38@usenet.arcornews.de> wrote:

>Am 25.03.2014 00:00, schrieb Phil:
>> On 24/03/2014 17:47:36, "Access Developer" wrote:
>>> "PW" <emailaddyinsig@ifIremember.com> wrote
>>>
>>>> I was doing that and the record was
>>>> getting saved w/o passing edits.
>>>> Put the Undo in the BeforeUpdate
>>>> event?
>>> There are several things that can cause the record to be updated, to wit,
>>> moving focus to a Subform control or an explicit save via keypress or code
>>> action, and moving off the current record to another record, or closing
>>> the form. You can't stop an Update in the After Update event because, of
>>> course, the update has already occurred. If you want to cancel, you must
>>> do so before the update occurs.
>>>
>>>> And isn't that just for new
>>>> records?
>>> No, Before Update event applies to all records being written. Before /
>>> After Insert applies only to new records.
>>>
>>>> What if the user blanks out a
>>>> required field in an existing record?
>>> As best I remember, if you defined the field as required in the table
>>> definition, the database engine will enforce that, and will not write a
>>> record without the field.
>>>
>>>> By the way, I saw many examples
>>>> from a search and they all do me.Undo,
>>>> and then Cancel=True.  Cancel=True
>>>> would not allow me to exit the form
>>>> using the X/Close button.  I don't even
>>>> know what it is supposed to do.
>>> Cancel = True does exactly what it says... it cancels writing / updating
>>> the record. I believe it does, by design, return you to the form. If
>>> there's still data in the form, and there's a problem that prevents the
>>> record being written, closing the form will not work.
>>>
>>> Larry Linson
>>> Microsoft Access MVP
>>> Co-Author, Microsoft Access Small Business Solutions, pub. by Wiley
>>>
>>>
>> This is a routine to check a post code has been entered
>>
>> Private Sub Form_BeforeUpdate(Cancel As Integer)
>>      
>>      If CheckPostCode = False Then
>>          DoCmd.CancelEvent
>>      End If
>>      
>> End Sub
>>
>> Function CheckPostCode() As Boolean
>>
>>      If Nz(PostCode) = "" Then
>> If If MsgBox("You have not entered the post code, Do you want to correct
>> this?", vbQuestion + vbYesNo) = vbNo Then             Me.Undo
>>              MsgBox "All changes have been discarded"
>>          Else
>>              PostCode.SetFocus
>>          End If
>>      Else
>>          CheckPostCode = True
>>      End If
>>      
>> End Function
>>
>> It works OK, but for some reason if you close the form there is an error
>> message to say it can't save the record (which is unchanged anyway)
>>
>> Phil
>>
>> ---
>> This email is free from viruses and malware because avast! Antivirus protection is active.
>> http://www.avast.com
>>
>Hi Phil,
>
>in the beforeupdate event you can suppress any updates of the database 
>table with the cancel variable set to true or running the macro 
>docmd.cancelevent but your current record of the form will still be 
>dirty! Just make a undo on the edited form or control to discard all 
>changes.  After that, you should be able to close your form, but ...
>If you are currently in a new record and have required fields in the 
>table then it is still not possible to save the record, because of the 
>validation rules. Try to check/debug the DataErr in the form error event 
>to get an idea what is preventing you from closing the form. Typical 
>error codes are 2169, 3022, 3314. You should always handle this codes in 
>the form error event too.
>
>Take a notice on the form properties "newrecord" and "dirty" in the 
>online help.
>
>If you use cancel in the beforeupdate event you also have to ensure that 
>the form.dirty and form.newrecord properties are both false when you 
>want to close the form otherwise you will trap in a classic loop.
>
>Ulrich
>

I just got back home to my PC and newsreader guys.  I can't try
anything out until Monday.  I'll reply then after I mess around with
everyone's suggestions.

Thanks so much everyone!

-paulw

[toc] | [prev] | [next] | [standalone]

#9194

"Phil" <phil@stantonfamily.co.uk> wrote > This is a routine to check a post 
code has been entered

  > Private Sub Form_BeforeUpdate(Cancel As Integer)
  >
  >    If CheckPostCode = False Then
  >        DoCmd.CancelEvent
  >    End If
  >
  > End Sub

You did not set the Cancel argument... try this instead.

  > Private Sub Form_BeforeUpdate(Cancel As Integer)
  >
  >    If CheckPostCode = False Then

          Cancel = True            'This cancels the _Update_

  >    End If
  >
  > End Sub

They provide the Cancel argument for a reason.  Read Help on the Cancel 
argument, and on DoCmd.CancelEvent. I do not remember that they are 
equivalent and that executing "DoCmd.CancelEvent" is a _replacement_ for 
setting "Cancel = True".

 -- 
 Larry Linson
  Microsoft Office Access MVP
  Co-Author, Microsoft Access Small Business Solutions, Wiley 2010
 

[toc] | [prev] | [next] | [standalone]

#9195

Am 25.03.2014 17:50, schrieb Access Developer:
> "Phil" <phil@stantonfamily.co.uk> wrote > This is a routine to check a post
> code has been entered
>
>    > Private Sub Form_BeforeUpdate(Cancel As Integer)
>    >
>    >    If CheckPostCode = False Then
>    >        DoCmd.CancelEvent
>    >    End If
>    >
>    > End Sub
>
> You did not set the Cancel argument... try this instead.
>
>    > Private Sub Form_BeforeUpdate(Cancel As Integer)
>    >
>    >    If CheckPostCode = False Then
>
>            Cancel = True            'This cancels the _Update_
>
>    >    End If
>    >
>    > End Sub
>
> They provide the Cancel argument for a reason.  Read Help on the Cancel
> argument, and on DoCmd.CancelEvent. I do not remember that they are
> equivalent and that executing "DoCmd.CancelEvent" is a _replacement_ for
> setting "Cancel = True".
>
>   --
>   Larry Linson
>    Microsoft Office Access MVP
>    Co-Author, Microsoft Access Small Business Solutions, Wiley 2010
>   
>
>

You can use the macro as a replacement for setting the cancel argument 
to true. This is equivalent at least in the form_beforeupdate  event and 
documented in the online help.  The effect is the same. There are some 
differences in the KeyPress and MouseDown events as described in the 
help file.

Nevertheless i prefer to not mix up vba programming and macros if there 
are no special reasons for that and would always use the cancel argument 
in this place.


Ulrich

[toc] | [prev] | [next] | [standalone]

#9197

I agree. I avoid macros in code, though it's sometimes either necessary or 
useful.

I know, from experience, that the Cancel = True approach works.

Either one, of course, must be used in the appropriate event.

 -- 
 Larry Linson
  Microsoft Office Access MVP
  Co-Author, Microsoft Access Small Business Solutions, Wiley 2010

"Ulrich Möller" <knobbi38@usenet.arcornews.de> wrote in message 
news:lgsl34$7jp$1@dont-email.me...
> Am 25.03.2014 17:50, schrieb Access Developer:
>> "Phil" <phil@stantonfamily.co.uk> wrote > This is a routine to check a 
>> post
>> code has been entered
>>
>>    > Private Sub Form_BeforeUpdate(Cancel As Integer)
>>    >
>>    >    If CheckPostCode = False Then
>>    >        DoCmd.CancelEvent
>>    >    End If
>>    >
>>    > End Sub
>>
>> You did not set the Cancel argument... try this instead.
>>
>>    > Private Sub Form_BeforeUpdate(Cancel As Integer)
>>    >
>>    >    If CheckPostCode = False Then
>>
>>            Cancel = True            'This cancels the _Update_
>>
>>    >    End If
>>    >
>>    > End Sub
>>
>> They provide the Cancel argument for a reason.  Read Help on the Cancel
>> argument, and on DoCmd.CancelEvent. I do not remember that they are
>> equivalent and that executing "DoCmd.CancelEvent" is a _replacement_ for
>> setting "Cancel = True".
>>
>>   --
>>   Larry Linson
>>    Microsoft Office Access MVP
>>    Co-Author, Microsoft Access Small Business Solutions, Wiley 2010
>>
>>
>
> You can use the macro as a replacement for setting the cancel argument to 
> true. This is equivalent at least in the form_beforeupdate  event and 
> documented in the online help.  The effect is the same. There are some 
> differences in the KeyPress and MouseDown events as described in the help 
> file.
>
> Nevertheless i prefer to not mix up vba programming and macros if there 
> are no special reasons for that and would always use the cancel argument 
> in this place.
>
>
> Ulrich
> 

[toc] | [prev] | [next] | [standalone]

#9198

On 25/03/2014 16:50:18, "Access Developer" wrote:
> "Phil" <phil@stantonfamily.co.uk> wrote > This is a routine to check a
> post code has been entered
> 
> > Private Sub Form_BeforeUpdate(Cancel As Integer)
> >
> >    If CheckPostCode = False Then
> >        DoCmd.CancelEvent
> >    End If
> >
> > End Sub
> 
> You did not set the Cancel argument... try this instead.
> 
> > Private Sub Form_BeforeUpdate(Cancel As Integer)
> >
> >    If CheckPostCode = False Then
> 
> Cancel = True            'This cancels the _Update_
> 
> >    End If
> >
> > End Sub
> 
> They provide the Cancel argument for a reason.  Read Help on the Cancel
> argument, and on DoCmd.CancelEvent. I do not remember that they are
> equivalent and that executing "DoCmd.CancelEvent" is a _replacement_ for
> setting "Cancel = True".
> 
> --
> Larry Linson
> Microsoft Office Access MVP
> Co-Author, Microsoft Access Small Business Solutions, Wiley 2010
> 
> 
> 


The office help file seems to imply that DoCmd.CancelEvent & Cancel = True
are equivalent

"All events that can be canceled in Visual Basic have a Cancel argument. You
can use this argument instead of the CancelEvent method to cancel the event.
The KeyPress event and MouseDown event (for right-clicking only) can be
canceled only in macros, not event procedures, so you must use the
CancelEvent action in a macro to cancel these events."

Interesting that they can’t spell cancelled correctly

I occasionally use “Cancel = True”, for no real reason, but use
DoCmd.CancelEvent in about 99% of cases. Somehow it psychologically it seems
a positive instruction rather than setting some airy fairy integer called
“Cancel” to true or False.

Phil

---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com

[toc] | [prev] | [next] | [standalone]

#9184

On Mon, 24 Mar 2014 07:53:05 -0700 (PDT), Patrick Finucane
<patrickfinucanetx@gmail.com> wrote:

>On Saturday, March 22, 2014 4:30:49 PM UTC-5, PW wrote:
>> Hi, And stay on the form if the user wants to, without blanking out the record. So if a required field was not filled out, I have a messagebox asking the user if they want to exit the form without saving the record. If they answer No, then I want to still have the form loaded and give them a chance to enter in the required information. If they answer yes, then I want to exit the form without Access automatically saving the record. I do not want to have to make all controls unbound and then have to write code to handle this (although I could, but it would take alot of time on some of these forms. I want to be consistent.). Does anyone have a routine to do this? -paulw
>
>If msgbox("Exit form?,vbYesNo,"Confirm") = vbYes then
>  Me.Undo
>Else
>  Me.SomeField.SetFocus
>Endif


The form still exits putting that code in the BeforeUpdate event.
Where should it go Patrick?

-paulw

[toc] | [prev] | [next] | [standalone]

#9185

On Monday, March 24, 2014 11:57:01 AM UTC-5, PW wrote:
> On Mon, 24 Mar 2014 07:53:05 -0700 (PDT), Patrick Finucane <patrickfinucanetx@gmail.com> wrote: >On Saturday, March 22, 2014 4:30:49 PM UTC-5, PW wrote: >> Hi, And stay on the form if the user wants to, without blanking out the record. So if a required field was not filled out, I have a messagebox asking the user if they want to exit the form without saving the record. If they answer No, then I want to still have the form loaded and give them a chance to enter in the required information. If they answer yes, then I want to exit the form without Access automatically saving the record. I do not want to have to make all controls unbound and then have to write code to handle this (although I could, but it would take alot of time on some of these forms. I want to be consistent.). Does anyone have a routine to do this? -paulw > >If msgbox("Exit form?,vbYesNo,"Confirm") = vbYes then > Me.Undo >Else > Me.SomeField.SetFocus >Endif The form still exits putting that code in the BeforeUpdate event. Where should it go Patrick? -paulw

Hmmm.  I thought BeforeUpdate would be a great (best) place to do so.  Best I can say is to put the word 
  STOP
before your code so you can step into debug mode and follow the bouncing line, see where it goes.

My code is...If you want to exit the Undo any changes else if you don't want to exit then set focus to some field in the form you specify.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.databases.ms-access

csiph-web