I could really use a hand on this one.
I'm sure it's simple as I'm at the beginner level with VBA.
I'm trying to get the module to fire on the before update event.
This is puzzling since I have another database where this works but, now I can't seem to recreate it.
Can anyone see what I'm missing?
The question is whether you provide the form with an updateable recordset AND whether you actually change something and then try to navigate or use other controls to do a save of the data.
When you imply that something is wrong, what tests have you tried to see if this works? Have you set a breakpoint on the event routine's first line of code? I saw what appeared to be a legit setup, but that is only part of the picture. To fire an event, you need both the linkage AND something that qualifies to fire the event.
Tell us mechanically what you are doing that you think should trigger the update. What do you enter, what do you click, in what order?
your code is not very valid. I fixed it so that you can point to your form as an actual string argument instead of an object. I've never really understood the difference between ME.UNDO and CANCEL = TRUE, so I added both of them in there. The solution lies with one of the other. I'm not sure which one deletes the field data, but you can test that yourself.
Why would this make any difference? There is nothing wrong with referring to a form object per se.
I've never really understood the difference between ME.UNDO and CANCEL = TRUE, so I added both of them in there. The solution lies with one of the other. I'm not sure which one deletes the field data, but you can test that yourself.
Cancel = True passes back to the parameter in the call telling Access to not complete the action that called the event. So the Update is cancelled if it is a BeforeUpdate Event. (There is no Cancel parameter on AfterUpdate for obvious reasons.)
Me.Undo discards the edits to the entire current record.
Use Me.controname.Undo to discard the changes to the control.
it doesn't, but if you use strings to refer to the object names instead of variables to refer to the objects themselves, you can avoid any unexpected quirks and possible version-to-version errors that Access is well known for sure. If I remember right, I've run into problems with code that used object variables. but that was long ago, so things might have changed since then.
Adam, the difference between Me.Undo and passing back Cancel as TRUE is this:
With Me.Undo, you erase ALL CHANGES made to data. If you want to edit the record content, you start over because Me.Undo is the logical opposite of Update. It makes the form match the underlying record (whereas the Update sequence makes the underlying record match the form.) If I recall this correctly, both Undo and Update allow the Current event to fire because after either one, the form and record now match.
With Cancel=TRUE, you simply block the update event - but nothing changes on the form. So if you were blocking because something was left undone, like perhaps a field was left blank that by rule had to be filled in, you could pop up a message box and do the Cancel=TRUE, but the user could continue the data editing without starting over.
Doc Man - I can see you're willing to help me learn, so I'm all ears. Thanks.
The purpose of the public function is to prevent the user from creating a new record prior to them filling in a couple of selected fields. Namely, the ProjectName, Engineer, and ProjectPhase.
Tab test: My 1st test amounted to entering a ProjectName and tabbing through the fields. Once I enter the ProjectName the form is dirty. I then start tabbing and even though there are empty fields that I've placed the "*" in the Tag property, the record gets created. Not what I want.
I take it the BeforeUpdate event does fire since the record is created but, the code in the BeforeUpdate event must not be working the way I want it to.
Code:
Cancel = ValidationOfControl(Me)
The pubic function should be returning a True when the control has both the "*" in the tag and is empty.
OH BOY.........................
It just hit me as I was typing this up!
The underlying table T_Project has a default value of 0.
This default value satisfies my public function ValidationOfControl.
I removed the default value and, wallah! It works.
So many things that can cause a guy hours of searching......
Adam, the difference between Me.Undo and passing back Cancel as TRUE is this:
With Me.Undo, you erase ALL CHANGES made to data. If you want to edit the record content, you start over because Me.Undo is the logical opposite of Update. It makes the form match the underlying record (whereas the Update sequence makes the underlying record match the form.) If I recall this correctly, both Undo and Update allow the Current event to fire because after either one, the form and record now match.
With Cancel=TRUE, you simply block the update event - but nothing changes on the form. So if you were blocking because something was left undone, like perhaps a field was left blank that by rule had to be filled in, you could pop up a message box and do the Cancel=TRUE, but the user could continue the data editing without starting over.
I appreciate your explanation of that, but you may not realize that such explanations might become a moot point in the future. don't you think that could be the case? what I mean is...so much software and stuff is available for free anymore that I've run into a few programmers over time that don't even bother to learn the "why's" regarding events that happen. if something doesn't work, they simply move on and try something else. I will never do that of course, but I might have to go along with it if future colleagues adopt that kind of attitude. corporations obviously can't afford to take on that attitude, but for small business people it certainly is an option as it probably doesn't cost them anything.
