Actually, it's more serious than that, on at least two counts --

1. Using End will cause the application to crash under some (hard to
predict) circumstances. Add-ins and class modules can be strangely affected
by the mere presence of the End statement (even if you don't call the
function that contains it).

2. As a matter of code design, a sub-procedure has no knowledge of the
context in which it is called. The calling procedure may well have some
cleaning up to do -- such as returning the app to visibility, re-enabling
things, etc.





"Bob Phillips" wrote in message
...
But VBA ain't VB6, and all the things you mention are probably exactly
what
he wants to happen, everything cleared down. The host application is still
running.

--
HTH

Bob Phillips

(replace somewhere in email address with gmail if mailing direct)

"Jonathan West" wrote in message
...

"Ardus Petus" wrote in message
...
Use the End instruction
Just End, not End Sub or End Function

In the VB6 newsgroups, that kind of advice can start a flamewar:-)

The problem with using End is well described in the VBA help file.

"Note The End statement stops code execution abruptly, without invoking
the Unload, QueryUnload, or Terminate event, or any other Visual Basic
code.
Code you have placed in the Unload, QueryUnload, and Terminate events of
forms and class modules is not executed. Objects created from class
modules
are destroyed, files opened using the Open statement are closed, and
memory
used by your program is freed. Object references held by other programs
are
invalidated.

The End statement provides a way to force your program to halt. For
normal
termination of a Visual Basic program, you should unload all forms. Your
program closes as soon as there are no other programs holding references
to
objects created from your public class modules and no code executing."


--
Regards
Jonathan West - Word MVP
www.intelligentdocuments.co.uk
Please reply to the newsgroup