Problem with Control's .Undo method

[Lyn]

Hi,
In the BeforeUpdate event of a textbox control I have the following
simplified code:-

Private Sub StartDate_BeforeUpdate(Cancel As Integer)
[some validation code -- the following code is executed if validation
fails]
MsgBox "StartDate Error -- Please Check and Re-Enter."
Me!StartDate.Undo
Debug.Print "After Undo: " & Me!StartDate
Cancel = True
[Code to reset some other stuff based on the "undone" StartDate]
GoTo ProcEnd
[...]
ProcEnd:
End Sub

When an error occurs, the original textbox value is restored at the end of
the Before Update event by the "Cancel = True" statement. The
"Me!StartDate.Undo" statement does nothing. The Debug.Print still shows the
invalid value.

The online Help for .Undo recommends using this method in the control's
Change event. Is this the only place it can be used for a control? Does it
not work in the BeforeUpdate event? Or am I coding it incorrectly?

The problem is that when the data is found to be invalid, I need to reset
some other fields based on the original value of the text box before leaving
the BeforeUpdate event. If .Undo does not work in this context, maybe I
should be trying .OldValue instead of the Undo method as the basis for
resetting the other stuff?

Any guidance appreciated.

--
Cheers,
Lyn.

[Lyn]

As usually happens when I post a question, I figure out the answer
immediately afterwards. Or at least I think I have in this case. Please
advise if I am right or wrong.

You can't Undo a control while it has focus. But the Catch-22 is that I
can't change focus in the BeforeUpdate event. Maybe I should move all the
code to AfterUpdate? Cancel is not available there, but as I am using a
manual Undo this probably won't matter?

--
Cheers,
Lyn.

"Lyn" <lh******@ihug.com.au> wrote in message
news:d5**********@lust.ihug.co.nz...

Hi,
In the BeforeUpdate event of a textbox control I have the following
simplified code:-

Private Sub StartDate_BeforeUpdate(Cancel As Integer)
[some validation code -- the following code is executed if validation
fails]
MsgBox "StartDate Error -- Please Check and Re-Enter."
Me!StartDate.Undo
Debug.Print "After Undo: " & Me!StartDate
Cancel = True
[Code to reset some other stuff based on the "undone" StartDate]
GoTo ProcEnd
[...]
ProcEnd:
End Sub

When an error occurs, the original textbox value is restored at the end of
the Before Update event by the "Cancel = True" statement. The
"Me!StartDate.Undo" statement does nothing. The Debug.Print still shows
the invalid value.

The online Help for .Undo recommends using this method in the control's
Change event. Is this the only place it can be used for a control? Does
it not work in the BeforeUpdate event? Or am I coding it incorrectly?

The problem is that when the data is found to be invalid, I need to reset
some other fields based on the original value of the text box before
leaving the BeforeUpdate event. If .Undo does not work in this context,
maybe I should be trying .OldValue instead of the Undo method as the basis
for resetting the other stuff?

Any guidance appreciated.

--
Cheers,
Lyn.

[Rick Brandt]

Lyn wrote:

As usually happens when I post a question, I figure out the answer
immediately afterwards. Or at least I think I have in this case. Please
advise if I am right or wrong.

You can't Undo a control while it has focus. [snip]

What gave you that idea? Undo is used a LOT in control's BeforeUpdate events
and by definition the control will have focus when that event is running.

--
I don't check the Email account attached
to this message. Send instead to...
RBrandt at Hunter dot com

[Lyn]

"Rick Brandt" <ri*********@hotmail.com> wrote in message
news:Lm****************@newssvr12.news.prodigy.com ...

Lyn wrote:

You can't Undo a control while it has focus. [snip]

What gave you that idea? Undo is used a LOT in control's BeforeUpdate
events and by definition the control will have focus when that event is
running.

Rick, thanks for your response.

I stand corrected. In retrospect, I realise that I didn't get an error
message to that effect whereas I have had other situations where this did
occur. I guess I "assumed" (and, yes, I know what "ass-u-me" means :-).

So if that is not the problem, why is Undo not working for me? I have since
got a workaround going where I simply copy .OldValue back into the control.
But isn't this basically what Undo does anyway?

--
Cheers,
Lyn.

[Rick Brandt]

Lyn wrote:

Rick, thanks for your response.

I stand corrected. In retrospect, I realise that I didn't get an
error message to that effect whereas I have had other situations
where this did occur. I guess I "assumed" (and, yes, I know what
"ass-u-me" means :-).

So if that is not the problem, why is Undo not working for me? I
have since got a workaround going where I simply copy .OldValue back
into the control. But isn't this basically what Undo does anyway?

Is it a required field? I have also found that Undo does not work as
desired if the control is bound to a required field. In my case it was a
small form with only a few fields so I used Undo on the entire form which
did work.

--
I don't check the Email account attached
to this message. Send instead to...
RBrandt at Hunter dot com

[Lyn]

"Rick Brandt" <ri*********@hotmail.com> wrote in message
news:HA****************@newssvr30.news.prodigy.com ...

Is it a required field? I have also found that Undo does not work as
desired if the control is bound to a required field. In my case it was a
small form with only a few fields so I used Undo on the entire form which
did work.

No, it is not a required field, but your response has triggered my addled
brain! The control in question is UNBOUND, so of course Undo won't work!

This is hard to explain, but basically I have a Start Date field in the
table, a corresponding bound but hidden date control on the form, and an
unbound text control which I use to display the date or a message if the
date is special (such as "Unknown"). The unbound field is a copy of the
hidden bound field if the date is a valid one. Applying the Undo to the
bound (hidden) control has resolved the problem.

A case of not seeing the woods for the trees. I think I have been working
on this for too long!

Thanks again for your help. One good thing -- this embarrassment will
ensure that I don't fall for the same problem again!

--
Cheers,
Lyn.