What are the differences between "end" and "unload"???

[iamtat]

If I want to exit from a program, then,
should I use "End"? or "Unload Me"?
Or any other method?

What are the differences between them?
Thanks!!

[Scott]

End will unload all the forms in the program and close it completely.
Unload will only unload the form that you specify and leave the others open.
If you have only one form in your project then either will do but get in the habbit of using end instead of unload to fully stop your program.

[cool_dude]

Lets say when you open your application 2 forms are loaded and visible. When you unload a form the other will be open until you unload the second one and then the program closes. But when you End a form it will unload all the forms and close your program.

[reboot]

End is bad. Don't use it. End terminates your program much like 'End Tasking' from Task Manager. It doesn't 'unload all forms'. It just kills the main process. Form Unload events are not called, Class Terminate events are not called.

The proper way to end your program is to unload all forms, close all objects, and set all objects = Nothing.

Please don't 'get into the habit' of using End.

[iamtat]

End is bad. Don't use it. End terminates your program much like 'End Tasking' from Task Manager. It doesn't 'unload all forms'. It just kills the main process. Form Unload events are not called, Class Terminate events are not called.

The proper way to end your program is to unload all forms, close all objects, and set all objects = Nothing.

Please don't 'get into the habit' of using End.

Thank you all you guys!!
Then, in what situation should I use end?
So, I should use for next loop to close all form and set the variable to nothing right?

[reboot]

There is almost never any good reason to use End.

[TeraBlight]

[...] and set all objects = Nothing.
This is apparently debatable: http://blogs.msdn.com/ericlippert/archive/2004/04/28/122259.aspx

[OnErr0r]

This is apparently debatable: http://blogs.msdn.com/ericlippert/archive/2004/04/28/122259.aspx

Interesting article, he makes some good points, thanks for linking it.

While it is not imperative that you set all objects equal to nothing, it is probably wise. It is true that when a local object is destroyed (goes out of scope) it's terminate event will be called. This is no different than setting the object equal to nothing (within the procedure), which also calls the terminate event. However, if the object has module wide scope (or even public scope) it will live until the application exits, unless you explicitly set it equal to nothing. If said object uses a lot of memory, you have to potential to use extra memory in your application that could otherwise be freed. Since you might not have a variable naming convention which tells you if an object is local, module or public, it might be confusing as to which object should be set equal to nothing and which should not. Since there is no harm in setting an object equal to nothing (aside from some superfluous code), I feel that all objects instantiated in a procedure should also be set equal to nothing.

The point made about order of setting to nothing is an important one too. In my GDI+ classes I have teardown code to free bitmap and graphics objects in the respective classes. Those objects must be disposed before the main GDI+ class object is disposed. This is because you cannot continue to make GDI+ API calls once GDI+ has been shutdown.

[loquin]

In the article, he uses CREATEOBJECT exclusively. He states that VB, when using createobject, WILL release objects without the requirement for explicitly releasing them. That may be so, but, I tend to avoid this technique when possible, as it produces less effecient object code.Dim cn
Set cn = CreateObject("ADODB.Connection") As ObjectPer MSDN,
Objects instantiated with CreateObject are late-bound, which means that they are not strongly typed and command-line completion is disabled. ... Instantiating objects with the CreateObject method is typically slower than using the Dim statement.
A second approach is to DIM an object as new, which implicitly instanciates it. This also ties the object to the scope in which it was instanciated, and the object is implicitly released when the code goes out of scope. No explicit release required, or desired. And, while the code produced is reasonably efficient, every operation that references the object has additional error checking to ensure that the object is open.Dim cn as New ADODB.Connection

'... Do stuff with the connection. Open it, close it, etc.

The third method, which I normally follow, produces the most effecient code, however, you MUST explicitly define, instanciate, and release the objects. If you do not, they will be orphaned when the code in which they are defined go out of scope.
Dim cn as ADODB.Connection

Set cn = New ADODB.Connection
'... Do stuff with the connection. Open it, close it, etc.
Set cn = Nothing

However, back to the original question: IF you use the END statement, all normal shutdown/cleanup steps that VB would normally take are bypassed, and the program ends abruptly. This means that ANY unreleased objects will NEVER get released, and, since the app that created them is no more, they will remain in memory until the computer is rebooted. This, my friends, is a form of a "memory leak."

[Lintz]

loquin, is there an advantage using this method
Dim cn As ADODB.Connection

Set cn = New ADODB.Connection
'... Do stuff with the connection. Open it, close it, etc.
Set cn = Nothing

Compared to...
Dim cn As New ADODB.Connection

'... Do stuff with the connection. Open it, close it, etc.


Is it better?

[Iceplug]

And, while the code produced is reasonably efficient, every operation that references the object has additional error checking to ensure that the object is open.
As far as my opinion, the top one is better because, clearly, you specify exactly when the object is consuming its resources and when they are freed, as with the bottom one, you have to just assume that its always open unless you clear it... which brings me to the real reason why I don't like the second one (it's creepy)

The second one creates this "zombie" instance of a class.
Dim Squeaks As New Mouse
Whiskers.TryCatch(Squeaks) 'let's say if Whiskers (the cat) catches the mouse,
then the mouse is set to Nothing

if you do
Squeaks.Hide() 'or any member of the mouse object...

you should rightly get the Object variable not set error

however, the Mouse object is alive!, even if it was set to nothing by the cat!
(Now, there's a zombie hiding in the house... get the garlic)

(and a zombie with values that you probably don't want to be there, leading to a bug in the code instead of an error)

[reboot]

This would be enough to convince me all by itself. Try

Dim cn As New ADODB.Connection
Set cn = Nothing

'some valid connection string
cn.Open "Provider=SQLOLEDB.1;Integrated Security=SSPI;" & _
"Persist Security Info=False;Initial Catalog=Northwind;" & _
"Data Source=thompson"


vs

Dim cn As ADODB.Connection
Set cn = New ADODB.Connection
Set cn = Nothing

'some valid connection string
cn.Open "Provider=SQLOLEDB.1;Integrated Security=SSPI;" & _
"Persist Security Info=False;Initial Catalog=Northwind;" & _
"Data Source=thompson"


The first one produces no error. The second correctly informs you that the object is not set.

[OnErr0r]

The third method, which I normally follow, produces the most effecient code, however, you MUST explicitly define, instanciate, and release the objects. If you do not, they will be orphaned when the code in which they are defined go out of scope.
Dim cn as ADODB.Connection

Set cn = New ADODB.Connection
'... Do stuff with the connection. Open it, close it, etc.
Set cn = Nothing



They actually won't be orphaned. When a local object goes out of scope it is destroyed. You can verify this by creating a simple class with a terminate event. Set a breakpoint and you'll notice it's fired regardless of whether you explicitly set the class object equal to nothing or not.

Matt Curland makes the point that this is actually less efficient (vbaCastObj vs vbaFreeObj). What I wonder is, how much of a performance hit that is, and whether it's worth it in place of consistantly destroying objects instead. Which definitely frees any memory used by the object immediately, regardless if it's local or not.