Your question's title tells me what you are thinking. The answer to the question along that particular line is "NO" - but do not despair. First, I'll explain the "NO." Then I'll tell you how to approach it.
You don't want to stay in the same event. You see, you can't have another event interrupt event code unless you run a DoEvents call. So any OTHER event won't occur if you stay in that event. However, having said that, I can add that it is possible to simplify your operation to single clicks.
You need two or three control buttons on the form. Maybe four or five. Save, Undo, and Quit are obvious. But also you could have "Save & New Scan" and "Scan"
You need to examine the events that occur on the form that might be of interest to you.
Form LOAD event - when the form first comes into memory, gets opened up for the first time, etc. - in this event you can set up your initial variables in the global declaration area of your class module. Including a boolean that you use to remember that someone used the "Save & New Scan" button. The LOAD event code must set it false.
Form CURRENT event - when a save, undo, or other record-oriented event has occurred, the CURRENT event is called after the previous sequence of events related to the previous record action is finished, if the form doesn't do an exit first. Hint: The first time the form is loaded, you do LOAD, then CURRENT. Each new cycle of actions begins with another CURRENT that DOESN'T follow a LOAD but might follow the AFTERUPDATE event of the previous cycle's actions.
The button click events will define what else you do. Each of these is a control-specific ONCLICK event.
Quit is obvious. But test whether you have a new record to be saved (Me.Dirty = TRUE), and disallow a quit with an unsaved record. You can write your own dialog box for this or just use a standard message box (recommended).
Save (with no qualifiers) saves the record. Period. When the record update is finished, you come back to the form, which would still be at the same record. (The CURRENT event would fire again when the save operation is complete.)
Undo erases the changes made to the current record. When the erasure is finished, you come back to the form with whatever content it had before you started, but the same record. (The CURRENT event would fire again.)
The new buttons are SAVE & NEW SCAN and SCAN.
For Scan, you do whatever it is that sets up the scanner. OK so far? Hint: Make the action a subroutine because you'll want to set up the scanner from more than one place. Such as is described for your other button.
The key is the Save & New Scan button. Here, you do the save action AND SET THAT FLAG I MENTIONED. OK, so you do the save just like the ordinary save button did it. Again, the CURRENT event fires when the old record is saved. BUT... this time, the CURRENT event can see that flag you set when you clicked the Save & New Scan button. So the CURRENT event can set up a new record and set up your scanner, too! (Told you a subroutine would be a good idea.) But the ONCURRENT event clears the Save/New flag once it sets up the new record. (Avoid interminable loops this way.)
Now, the procedure becomes: Open form. Click SCAN button. Scan. NOW click SAVE & NEW SCAN button. Scan. Repeat until you can't stand it any more. Now just click the SAVE button. not the SAVE/NEW button. When the CURRENT event fires the next time, the flag is clear (because you cleared it the previous time the ONCURRENT event fired.) You don't get a new record, the old one stays put. Now just click the QUIT button. Since you last did a SAVE, your form isn't "dirty" (Me.Dirty property is FALSE). So you can exit the form safely.
