Undo typing

[Pat Hartman]

Keep in mind that if you don't want to teach people to use esc to clear the previous field, the problem becomes much more complicated AND the control must be on the form where the control is. So, you can't use a control on a main form to "undo" something on the subform. PERIOD. Why? because moving focus from the subform to the main form, saves the subform record and so there is no way to undo it once it is saved. Moving control from the main form to the subform, saves the main form record whether you asked Access to do it or not. And that is one of the main reasons for putting the validation code in the Form's BeforeUpdate event rather than some random form or control event.

Also, in a mainform/subform situation, your cancel button won't work once you have moved focus to the subform because you can't undo something that was already saved.

 

[The_Doc_Man]

We keep on coming up with a control button to do this, but if you look at the original question, the simple answer is "Not Possible" because... if you click on a command button, guess where focus IMMEDIATELY lands? The new control button. The reason you use CTRL/Z or ESC rather than some command button is because neither of the keystrokes change focus. Their functionality in this case depends on not moving focus.

Before I get being accused of being too harsh and negative, the complex answer is "May be possible under some circumstances." It would be possible to build a feature using <control>.LostFocus on your various controls to always record the name of the control that previously had focus. Or as Gasman suggested, use the Screen.PreviousControl.Name to find the name of that control.

If you had this putative "dynamic UNDO" button, you would click it and have it execute an .Undo on the previous control using something like Me.Controls(previous-name).Undo - but with a caveat. UNDO merely makes the control match the .OldValue, so to be useful, the control in question has to HAVE an .OldValue, and not every control does. For instance, unbound controls don't. Also, if you edit something and then tab through a couple of controls without typing, then realize that you wanted to undo something that was changed two or more controls ago, it is already too late to use that method.

 

[JMongi]

Sometimes it helps to take a bigger picture approach:

Why do you REALLY need this functionality?

Data entry mistakes get made all of the time. In practical terms you are reducing your "wrong info" percentage from .5% to .1% (made up numbers) because in order to use any type of undo requires the user to recognize the mistake within the timeframe allowed. This feature is merely extending the window of opportunity to both recognize and correct a mistake. Perfect data entry is an impossibility.

So, is this process easier and more beneficial than simply going back in and editing a record? Does the form setup not allow this? Is there some other business reason why correcting the data at a later point in time is more cumbersome and time-consuming than trying to implement this system? Is it a particular attribute that needs to be reviewed?

This isn't meant as any type of criticism at all. You know your business needs better than we do. However, this thread started as a discussion of a specific potential solution to a problem. You may find a better way by discussing the problem itself and its consequences you are trying to avoid. That may illuminate another path that until now has been obscured.

My 2 cents anyway

 

[twgonder]

Why?, well you see those two little buttons up on the QATB (at least on my version of Access) for undo and redo? They work different than ctrl-z and ctrl-y and escape.
And pressing them doesn't lose focus of where you are on the form, does it?
The other reason, when I release a secured production version, all those buttons and ribbons are history.
The user will be expected to do all their entry work in the forms.

 

[Pat Hartman]

Let us start with - Access is a Rapid Application Development (RAD) tool. It is not naked code like C where you have to build every single thing you want by writing code. Certain things like Forms are created for you as classes to save you an enormous amount of work. These classes contain "hooks" called event procedures where you can insert your own code to react to some interface action taken by the user. Event procedures are connected to forms and controls and if you review their names you can identify the action they respond to. When your Access app is running, it is being run by the Access.exe which is the puppeteer. You get only what the puppeteer allows. If only your left leg bends at the knee, then you can't get down on both knees and that is simply that. You are expecting to be working with C without doing any of the work. Maybe you should think about using a different development tool.

We have explained to you why a button on the main form cannot be used to undo an action on the subform because of the way main forms and subforms interact. The Access.exe is doing stuff for you. Granted you didn't ask it to do this stuff but it comes with the package. So you understand your tool and learn to work with it or you get a different tool. Access.exe is programmed to automagically save a subform record if it is dirty when you switch focus to the main form. Touching a button on a mainform generates the Click event for the button you touched and that requires that focus be on the main form. So - you have options listed in order of preference.
1. teach the user how to use the exc key ONCE to back out the most recently modified control or twice to back out all updates to the current record.
2. Add the undo button to the subform where it will work EXACTLY the way you want it to work.
3. Always ask the user if he wants to save a record he left without pressing your save button. This simply trains users to click OK to all your prompts and never to read anything. That is how annoying this method is.
4. Try to work with the SendKeys to capture certain keystrokes and figure out what control was the last one to have focus. This is dangerous and prone to error but have at it.