Cancel=True vs DoCmd.CancelEvent

[Deleted member 65619]

Hey All,

I was wondering if anyone could clearly explain the difference between Cancel = True and DoCmd.CancelEvent. I've been using doCmd.CancelEvent but I'm unable to really see a difference between the two and the pros and cons to using either. If you have a great link that clearly explains it, that would be very much appreciated as well.

I've been searching but haven't really found a clear explaination that warrants one over the other. It seems Cancel = True/False and storing it as an integer is the only real difference. I did see one user mention that CancelEvent is an actual event where cancel just stops and doesn't trigger an unknown event. However, I wasn't sure if that was true.

Thanks,
J

 

[MarkK]

From VBA help under DoCmd.CancelEvent...

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.

This seems to suggest that from a functional perspective there is no difference.

I avoid DoCmd because it is commonly more verbose and it looks ugly, like, compare...

   DoCmd.SetWarnings False
   DoCmd.RunSQL SQL
   DoCmd.SetWarnings True
[COLOR="Green"]   ' vs[/COLOR]
   CurrentDb.Execute SQL, dbFailOnError

   If DataIsNotValid Then
      DoCmd.CancelEvent
   End If
[COLOR="green"]   ' vs[/COLOR]
   Cancel = DataIsNotValid

   DoCmd.GoToRecord acDataForm, Me.Name, acNext
[COLOR="green"]   ' vs[/COLOR]
   Me.Recordset.Movenext

IMO, using DoCmd is more verbose, and looks uglier in code.
Mark

 

[Pat Hartman]

Here's a link to a help entry. Although the CancelEvent seems to be a macro action, it can be used in VBA by using DoCmd. I guess that's why I've always used Cancel = True since it is VBA only.

There is no indication that they operate differently.

https://msdn.microsoft.com/en-us/vba/access-vba/articles/docmd-cancelevent-method-access

 

[Deleted member 65619]

Ahh that helps! Thanks gents

 

[The_Doc_Man]

I don't know the exact mechanism used by DoCmd but in the case of just setting the Cancel parameter to True, the mechanism is essentially a simple argument passage, probably has to be ByRef to be effective.

I'm betting that the "Cancel=True" syntax gets compiled into code that is A LOT smaller than the code for a DoCmd.xxx, but since there is no feature to show us the exact translation of compiled VBA, we have no way to really answer this with 100% certainty.

 

[Deleted member 65619]

Interesting and good to know! Thanks, Doc

 

[missinglinq]

Also, going by what I've seen over the years, both here and on half-a-dozen other Access sites, using

DoCmd.CancelEvent

can be problematic, at times. The problems include, but aren't limited to, people using it when a given event is not one that can be cancelled, such as a Command Button's OnClick event.

Linq ;0)>

 

[The_Doc_Man]

Good point, Linq!

There is a point I make along those lines regarding sequential event firing, such as the Form Open, Load, Current, Activate, Enter sequence. The only one of the sequence that CAN be canceled is Open, and that is how you enforce any restrictions on opening a form based on user role. If you use the "Cancel = True" mechanism, you use it because the event CAN be canceled, and the form wizard will build the correct calling sequence for you to apply it.

I.e. use the wizard to create the scaffold for every event you are going to build because the wizard has the correct template for every event. It is then very easy to go back and customize the event code once the scaffolding is in place. And that means you will ALWAYS have the "Cancel = True" option available if it applies to that event.

 

[Deleted member 65619]

Great points!

Ahh that could be why my CancelEvents seem to inconsistently work or at times inexplicably have issues.

Great idea, doc! That will help me get to know the correct structure for each event better.

Looks like I'm going to start switching over to the light side of the force Cancel = TRUE :banghead::banghead: