Would like advice on resetting form controls after Undo

[Jon A]

I have a bunch of controls on my form, and the state of each
control is based on the state of the overall form. That is,
when the status of the record is "Open" then certain
controls are enabled and certain others are disabled. When
the status of the record is "Closed" then just about all the
controls are disabled, etc., etc.

The controls consist of mostly text boxes, but there are
some command buttons also and a couple of combo boxes.

My problem is when I hit the ESC key to perform an Undo.

The data in all the controls get reset correctly to their
original values. But not all the controls do.

I have a procedure that gets called on Form_Current,
Form_AfterUpdate, Form_Undo, etc. It works to correctly
reset the controls all the other times but not with Undo.

When I go to the debugger and place a breakpoint in that
procedure I can check the values of the control variables.
The controls all seem to hold the new value that was typed
in rather than the original value that shows on the screen.

For example, if a text box was empty when I opened up the
form, then I type something in it, then I hit ESC - the text
box control on the form shows that it has nothing in it.

But then when I break and hold the cursor over the variable
Me![MyTextBox] in the code, it shows the value that was
typed in when it should be NULL.

As a result, when I perform the checks to setting the state
of the controls by doing things like:

if IsNull(Me![MyTextBox]) Then...

the wrong branch of the code executes and the control states
are wrong.

Is there some special way that I have to check the contents
of controls after hitting the ESC key?

 

[Brendan Reynolds]

I gave up trying to use the Undo event some time ago. In my experience,
pretty much anything I would want to do with an Undo event would require two
of them, BeforeUndo and AfterUndo I don't find the single Undo event useful.
When I really need to do something like this I use the Timer event instead.

That said, though, I can not reproduce the problem you describe. Here's the
code I used to attempt to reproduce it ...

Private Sub Form_Undo(Cancel As Integer)
Debug.Print Me.Controls("AnswerExpected").Value
End Sub

If, before the Undo event, the text box had the value Null, then Null is
what I see printed to the Immediate window.

Is it possible that your text box may contain an empty string rather than a
Null? (There is no visible difference). Try changing the test condition from
"If IsNull(TheTextBox)" to "If Len(TheTextBox & vbNullString) = 0" - this
will catch both Null values and empty strings.

 

[Jon A]

No, I put in some debug statements to test each of the
possibilities: NULL, empty, "", and all. It seems that the
original value is printed out correctly in the debug
statements. however, still when I place a breakpoint in the
code where the comparison is being done, and I hover the
mouse pointer over the variable name, a little yellow box
pops up with the value of the variable. Even though the
debug statement prints out the original value, the yellow
box shows the last-typed value. So the comparisons don't
seem to work correctly.

This doesn't always happen - only sometimes. I haven't
figured out what makes it do what it does sometimes and not
other times -- obviously or I wouldn't be having this
problem.

I'll keep working on it.

 

[MacDermott]

Remember that MyControl.Value (default property) displays the current value
of the control.
If focus is on MyControl, then MyControl.Text will show what's actually
displayed in it - even though it may not have been committed.
MyControl.OldValue contains the value the last time the record was saved.
Especially when MyControl has the focus, these values may or may not be the
same.

HTH