Exit VBA processing

Galaxiom

Super Moderator
Staff member
Local time
Tomorrow, 07:51
Joined
Jan 20, 2009
Messages
12,895
Exit Sub terminates the current procedure.
If this Sub was called by another procedure VBA returns and continues processing the original procedure.

Is there a command to tell VBA to exit all processing until another event trigger?

Thanks
 
You should handle this in a controlled manner by passing information back up the calling procedure tree. (There's no way to enumerate the callstack itself unfortunately :-p)

If you have need of terminating at a point - then using functions instead of procedures will allow you to pass back up a return value to indicate that no further action should be taken and each procedure then calls an Exit.
This is the correct, controlled manner by which to exit.

The alternative (which you shouldn't use) is "End".
This command is directly analogous to clicking the "Stop" (or Reset) button in the VBE standard menubar.
It halts (ends) all running code. But just as when chosen from a raised error - this command kills all objects, all public variables. It literally resets your VBA project.
A bit like getting your alarm clock to stop with a sledgehammer.

Cheers.
 
Look at "DemoExitVBAA2000.mdb" (attachmetn, zip).
 

Attachments

as much as the above examples how, perhaps the real question to ask is why?

in an event driven environment, each segment of code ought to be free-standing. if an individual piece of code needs to be stopped for some reason, then this should really have no effect on the rest of the programme, which should just sit there waiting for another event

so what are you trying to do? - in what circumstances are you trying to abort your procedures(s)?
 
Well, in a modular application (where our class and standard modules have been separated out into discrete objects - some of which will make use of others) then there will be occasions where a failure in some utility object would want to be reacted to higher up the call stack (e.g. halt whatever action was in process).

Certainly - in an event driven environment - there will then be subsequent events raised by the application or user, but a single given action may want to be halted (which happened to be calling other procedures or objects which may have raised an error).
 
Thanks for the perspectives on this subject. I was just checking to see if I was using more code than needed but it appears not.

In my project I have a subform showing the datasheet view of a query. Clicking on a row loads the related records into the main form for editing using the OnCurrent event. This calls another procedure that checks for updated form fields related to the loaded record and offers to save the changes before continuing.

This second procedure uses a YesNoCancel dialog. A Yes or No response deals with the changes as required and returns the control back to the OnCurrent procedure which then continues with loading the newly selected record.

A Cancel response returns the focus back to the unsaved record and exits the procedure. At this point there is nothing more for the OnCurrent procedure to do, so the cancel response must be tested again by the OnCurrent procedure causing it to exit rather than load the record over the top of the changes. Essentially this is done just as MStef's example shows.

I thought maybe I could take a shortcut by quiting all the processing in the save changed record procedure especially since it is also called by a number of other events besides the OnCurrent procedure and each one had to include the repeated test to exit if it finds a Cancel response.
 

Users who are viewing this thread

Back
Top Bottom