Visual Basic - How to End vb program

Author

How to End vb program

gary

2006-04-28, 6:56 pm

I have a program with a lot of forms. There are a number of places
where I need to end the program.

Would something like this be the proper way?

Dim frm As Form
For Each frm In Forms
If frm.Name <> Me.Name Then Unload frm
Next frm
Unload Me

Thanks,

Gary

Matthew Connor

2006-04-28, 6:56 pm

Gary, that should do the trick! The only change I would make is:

Dim frm As Form
For Each frm In Forms
If frm.Name <> Me.Name Then Unload frm
Next frm
End '<--Change Made

Mike Williams

2006-04-28, 6:56 pm

"Matthew Connor" <connah@gmail.com> wrote in message
news:1146249504.364504.274040@i40g2000cwc.googlegroups.com...

> Gary, that should do the trick! The only change I would make is:
> End '<--Change Made

Oh my God! You've gone and done it now! You've opened up that can of worms
again!

Mike

Rick Rothstein

2006-04-28, 6:56 pm

> Gary, that should do the trick! The only change I would make is:
>
> Dim frm As Form
> For Each frm In Forms
> If frm.Name <> Me.Name Then Unload frm
> Next frm
> End '<--Change Made

From an old post of mine...

Never, never, never, never, ever use the End statement to terminate your
program.

End should ***NEVER*** be used in VB. When you start writing more complex
code, you will find that in certain situations, VB needs to do some cleaning
up (and you need to help it). You can go to this Google newsgroup link

http://groups.google.co.uk/advanced...as_ugroup=*.vb*

and look up the exact word "vb" and the exact phrase "end statement" (leave
off the quotes in both of these) to find the many ways people have explained
the why and what of not using the End statement. Suffice it to say that the
End statement stops your program in the same way running into a brick wall
stops your car... immediately. You don't get a chance to coast to a stop and
turn your key to the off position, open the door and exit the vehicle. The
same thing happens with the End statement... BOOM!, everything stops dead in
its tracks right then and there and the program ends. The moral is... NEVER,
NEVER, NEVER use the End statement in your program! (And, in the same way,
using that "solid square" icon on VB's Toolbar, or clicking End in the Run
menu, to stop your project during development is the identical equivalent of
executing an End statement in code... you shouldn't do that either.)

Consider this... From the VB Help Files: "More About Forms"

"The End statement ends an application immediately: no code after the End
statement is executed, and no further events occur. In particular, Visual
Basic will not execute the QueryUnload, Unload or Terminate event procedures
for any forms. Object references will be freed, but if you have defined your
own classes, Visual Basic will not execute the Terminate events of objects
created from your classes."

"In addition to the End statement, the Stop statement halts an application.
However, you should use the Stop statement only while debugging, because it
does not free references to objects."

Rick

Tom Esh

2006-04-28, 6:56 pm

On Fri, 28 Apr 2006 19:52:52 +0100, "Mike Williams"
<mike@WhiskyAndCoke.com> wrote:

>
>Oh my God! You've gone and done it now! You've opened up that can of worms
>again!

The good thing about End is it's small and often hard to spot. That
way when the app breaks you've got maybe a day or so head start to
find a new job. <g>

-Tom
MVP - Visual Basic
(please post replies to the newsgroup)

Bob Butler

2006-04-28, 6:56 pm

"gary" <gary5x8@juno.com> wrote in message
news:mct4g.56$MA5.1418@news.uswest.net
> I have a program with a lot of forms. There are a number of places
> where I need to end the program.
>
> Would something like this be the proper way?
>
> Dim frm As Form
> For Each frm In Forms
> If frm.Name <> Me.Name Then Unload frm
> Next frm
> Unload Me

There's no need to avoid unloading the form the code is in and the code
above won't work if you have more then 1 form loaded with the same name.
IMO it's usually better to explicitly unload the known forms but if you must
do it that way then simplify it to
for each frm in forms
unload frm
next

And I'm not even going to think about the post where you added END in an
apparent attempt to generate a fatal error or possibly corrupt data
somewhere along the line.

--
Reply to the group so all can participate
VB.Net: "Fool me once..."

Ken Halter

2006-04-28, 6:56 pm

Bob O`Bob

2006-04-28, 6:56 pm

Bob Butler wrote:

> There's no need to avoid unloading the form the code is in and the code
> above won't work if you have more then 1 form loaded with the same name.
> IMO it's usually better to explicitly unload the known forms but if you must
> do it that way then simplify it to
> for each frm in forms
> unload frm
> next

It can get even simpler:

While forms.count
unload forms(0)
wend

No need for the overhead of instantiateing a reference variable, or iterating
through the collection.

Of course either way, if some form cancels the unload, trouble may ensue.

Chris Dunaway

2006-04-28, 6:56 pm

Bob O`Bob wrote:
> It can get even simpler:
>
> While forms.count
> unload forms(0)
> wend
>

I'm not sure how that is simpler that Bob Butler's version but in any
case, Forms.Count is not a boolean expression which is what the While
statement needs. While VB may treat it correctly, IMO it should be
avoided and that it is better to explicly state what you mean.

While forms.count > 0
Unload forms(0)
Wend

Bob Butler

2006-04-28, 6:56 pm

"Chris Dunaway" <dunawayc@gmail.com> wrote in message
news:1146257629.835736.293030@u72g2000cwu.googlegroups.com
> Bob O`Bob wrote:
>
> I'm not sure how that is simpler that Bob Butler's version but in any
> case, Forms.Count is not a boolean expression which is what the While
> statement needs. While VB may treat it correctly, IMO it should be
> avoided and that it is better to explicly state what you mean.
>
> While forms.count > 0
> Unload forms(0)
> Wend

it also has the issue that if a form doesn't unload it loops forever; the
earlier versions really need a test afterwards to look for any forms left
loaded to be really complete.

--
Reply to the group so all can participate
VB.Net: "Fool me once..."

Ken Halter

2006-04-28, 6:56 pm

"Chris Dunaway" <dunawayc@gmail.com> wrote in message
news:1146257629.835736.293030@u72g2000cwu.googlegroups.com...
> Bob O`Bob wrote:
>
> I'm not sure how that is simpler that Bob Butler's version but in any
> case, Forms.Count is not a boolean expression which is what the While
> statement needs. While VB may treat it correctly, IMO it should be
> avoided and that it is better to explicly state what you mean.
>
> While forms.count > 0
> Unload forms(0)
> Wend

While I don't use syntax like that due to readability problems (always
having to remember which way it's going to teeter <g> ), Bob'O's code does
evaluate to a boolean.

Similar to
'==
Dim i As Integer

i = 0

If i Then 'test for i <> 0
Do Something
End If
'==

I've always preferred the

If i <> 0 Then 'syntax.

--
Ken Halter - MS-MVP-VB - Please keep all discussions in the groups..
DLL Hell problems? Try ComGuard - http://www.vbsight.com/ComGuard.htm

gary

2006-04-28, 6:56 pm

Bob O`Bob wrote:
> Bob Butler wrote:
>
>
>
> It can get even simpler:
>
> While forms.count
> unload forms(0)
> wend
>
> No need for the overhead of instantiateing a reference variable, or
> iterating
> through the collection.
>
> Of course either way, if some form cancels the unload, trouble may ensue.
>

Won't this cause a loop. forms.count won't be 0 until this form is
unloaded.

Bob O`Bob

2006-04-28, 6:56 pm

gary wrote:
> Bob O`Bob wrote:
>
>
> Won't this cause a loop. forms.count won't be 0 until this form is
> unloaded.
>

see for yourself:

Option Explicit

Private Sub Command1_Click()
Dim x As New Form1
Load x
Debug.Print Forms.Count
End Sub

Private Sub Command2_Click()
While Forms.Count
Unload Forms(0)
Debug.Print Forms.Count
Wend
End Sub

Larry Serflaten

2006-04-28, 6:56 pm

> > Bob O`Bob wrote:

> see for yourself:
>
> Option Explicit
>
> Private Sub Command1_Click()
> Dim x As New Form1
> Load x
> Debug.Print Forms.Count
> End Sub
>
> Private Sub Command2_Click()
> While Forms.Count
> Unload Forms(0)
> Debug.Print Forms.Count
> Wend
> End Sub

Private Sub Form_QueryUnload(Cancel As Integer, UnloadMode As Integer)
Cancel = (vbNo = MsgBox("Do you really want to quit?", vbYesNo))
End Sub

<g>
LFS

Bob O`Bob

2006-04-28, 6:56 pm

Larry Serflaten wrote:
>
>
> Private Sub Form_QueryUnload(Cancel As Integer, UnloadMode As Integer)
> Cancel = (vbNo = MsgBox("Do you really want to quit?", vbYesNo))
> End Sub
>

Yeah - and I already said so, up-thread

gary

2006-04-28, 6:56 pm

Bob O`Bob wrote:
> gary wrote:
>
>
> see for yourself:
>
> Option Explicit
>
> Private Sub Command1_Click()
> Dim x As New Form1
> Load x
> Debug.Print Forms.Count
> End Sub
>
> Private Sub Command2_Click()
> While Forms.Count
> Unload Forms(0)
> Debug.Print Forms.Count
> Wend
> End Sub
>
OK. I tried it in the Unload event. There it loops.

Thanks for all the comments.

Gary

Michael C

2006-04-28, 9:56 pm

"gary" <gary5x8@juno.com> wrote in message
news:mct4g.56$MA5.1418@news.uswest.net...
>I have a program with a lot of forms. There are a number of places where I
>need to end the program.
>
> Would something like this be the proper way?
>
> Dim frm As Form
> For Each frm In Forms
> If frm.Name <> Me.Name Then Unload frm
> Next frm
> Unload Me

Hi Gary,

The question is pretty common and always gets some pretty poor responses.
There's a few problems with what you've got here. The main one is that it
masks problems in your app. You could have 100 hidden forms floating around
in memory that shouldn't be there and you will never be alerted to the
problem. Having this code as a backup in case things go wrong on the end
users machine is ok but you should have something to alert you to problems
in developement.

The other problem someone pointed out was it's not a good idea to compare
forms on name because 2 forms could have the same name. A better method
would be to use "If not frm is Me". This doesn't just apply to this
situation, for example you shouldn't do things like "if TypeName(x) =
"Form1"". This would be much better written as "If TypeOf x is Form1".

I would write the code like this:

Dim frm As Form
For Each frm In Forms
If not frm is me Then
Unload frm
Debug.Assert False
end if
Next
Unload Me

Although then again, I wouldn't write it at all. I don't have anything like
this in any of my apps. I would just use Unload Me on it's own.

Michael

gary

2006-04-28, 9:56 pm

Michael C wrote:
> "gary" <gary5x8@juno.com> wrote in message
> news:mct4g.56$MA5.1418@news.uswest.net...
>
>
>
> Hi Gary,
>
> The question is pretty common and always gets some pretty poor responses.
> There's a few problems with what you've got here. The main one is that it
> masks problems in your app. You could have 100 hidden forms floating around
> in memory that shouldn't be there and you will never be alerted to the
> problem. Having this code as a backup in case things go wrong on the end
> users machine is ok but you should have something to alert you to problems
> in developement.
>
> The other problem someone pointed out was it's not a good idea to compare
> forms on name because 2 forms could have the same name. A better method
> would be to use "If not frm is Me". This doesn't just apply to this
> situation, for example you shouldn't do things like "if TypeName(x) =
> "Form1"". This would be much better written as "If TypeOf x is Form1".
>
> I would write the code like this:
>
> Dim frm As Form
> For Each frm In Forms
> If not frm is me Then
> Unload frm
> Debug.Assert False
> end if
> Next
> Unload Me
>
> Although then again, I wouldn't write it at all. I don't have anything like
> this in any of my apps. I would just use Unload Me on it's own.
>
> Michael
>
>
Michael,

Do I understand correctly that you only have 1 form loaded at any given
time?

If a program moves between a number forms is it not better to leave them
loaded and just hide them when not in use? Especially since some of
these forms open files and load the contents into the form.

Stefan Berglund

2006-04-29, 3:56 am

On Fri, 28 Apr 2006 19:54:02 -0700, gary <gary5x8@juno.com> wrote:
in <wzA4g.68$MA5.3155@news.uswest.net>

>Michael C wrote:
>Michael,
>
>Do I understand correctly that you only have 1 form loaded at any given
>time?
>
>If a program moves between a number forms is it not better to leave them
>loaded and just hide them when not in use? Especially since some of
>these forms open files and load the contents into the form.

The answer to that depends of course on how your app is designed.

---
This posting is provided "AS IS" with no warranties and no guarantees either express or implied.

Stefan Berglund

Mike Scirocco

2006-04-29, 3:56 am

Stefan Berglund wrote:
> On Fri, 28 Apr 2006 19:54:02 -0700, gary <gary5x8@juno.com> wrote:
>
[color=darkred]
>
> The answer to that depends of course on how your app is designed.

Good point, reminds me of some other items on the list: exiting loops,
stopping downloads, stopping timers, destroying objects...

Michael C

2006-04-29, 3:56 am

"gary" <gary5x8@juno.com> wrote in message
news:wzA4g.68$MA5.3155@news.uswest.net...
> Michael,
>
> Do I understand correctly that you only have 1 form loaded at any given
> time?

No. My app can have many forms open but will have one main form, usually an
MDI parent. Unloading the MDI parent will unload all child forms. Any modal
forms are not a problem because they get unloaded when closed. Sometimes I
have floating windows but these will be stored in a module level variable on
a form somewhere and will be unloaded when that form gets unloaded.

> If a program moves between a number forms is it not better to leave them
> loaded and just hide them when not in use? Especially since some of these
> forms open files and load the contents into the form.

Generally I would say no, and you certainly should not do this as standard
practice. Maybe in some rare cases I would do this but it would be extremely
rare. If a large amount of data needed to be stored then I'd possibly store
it outside the form, that way the user interface would be quick to load but
the data would stay in memory. But that would lead to other problems such as
high memory usage or the program storing old data. When it might be useful
is if you have a form that is closed and opened on a very regular basis, say
a floating window that appeared when certain controls had focus.

Michael

Sponsored Links