To End Or Not To End. But How To End
in [Visual Basic]
|
From: Bob Butler on 6 Apr 2010 15:54 "Mike B" <mDotByerley(a)VerizonDottieNettie> wrote in message news:OHOihwb1KHA.5328(a)TK2MSFTNGP04.phx.gbl... > > "Karl E. Peterson" <karl(a)exmvps.org> wrote in message > news:%23qH00Kb1KHA.4560(a)TK2MSFTNGP02.phx.gbl... >> Bee wrote: >>> Why would MS include End if I cannot or should not use it, etc? >> >> Because MSFT used to give a damn about forward compatibility. That is, >> code once written and tested would continue to function the same in >> subsequent versions of the language. END goes back to the very earliest >> days of BASIC. It indeed had a very legitimate place in the language at >> that time. With the advent of VB, and the accompanying paradigm shift >> from procedural to event-driven execution, END became potentially >> dangerous. Still, it was there, so that old code would continue to >> execute just as it always had. Gotta hand it to Microsoft, back then, >> when an actual coder held the reins. > > Looks like they're set to pi$$ off a whole other bunch of sw developers. > > http://www.codeguru.com/daily_news/article.php/397018 d�j� vu all over again
From: MikeD on 6 Apr 2010 16:08 "C. Kevin Provance" <*@*.*> wrote in message news:uIGTdtP1KHA.4548(a)TK2MSFTNGP06.phx.gbl... > > "Nobody" <trinity(a)nobody.com> wrote in message > news:OTB3hmN1KHA.260(a)TK2MSFTNGP05.phx.gbl... > : It could have been just as easy to say "Have you tried Google?" But > : doing that prevents once from showing if they > : are an a$$hole or not. Sometime sit is important to some people that > : they demonstrate to as many people as possible > : that yes, they can be an a$$hole instead of a civil person. > > I've made that suggestion multiple times, and it's been ignored. If you > didn't read those replies from me...oh well, what can I do? I'm sure if > you Google "Google is your friend in this regard", it'll come up a few > times. > > As as far as your opinion of me, I tend not to lend any real credibility > to those who go out of their way to remain anonymous...I don't care how > helpful or "knowledgeable" you are. If you want to label me, do it to me > under your real name, man to man. Otherwise it's a coward move. You also > should know this by now. > > At least numbwits like Paul and Tom have the balls to use their name to > take their swipes. What's your excuse, besides being "Nobody"? You're just trouncing on everybody now, aren't you? <g> Who pissed you off? <g>
From: Helmut Meukel on 6 Apr 2010 16:09 "Nobody" <nobody(a)nobody.com> schrieb im Newsbeitrag news:erTf4Xa1KHA.5828(a)TK2MSFTNGP02.phx.gbl... > "Helmut Meukel" <NoSpam(a)NoProvider.de> wrote in message > news:Ob2PUNa1KHA.2028(a)TK2MSFTNGP05.phx.gbl... >> >> As many suggestions made for avoiding End this one is plain wrong! >> The Timer control that comes with VB6 is shut down automatically >> when you unload the form it is placed on! > > It doesn't shut down until Form_Unload is finished executing. If there is code > there that waits for something and calls DoEvents, Timer events will still > fire, however, they don't fire if not calling DoEvents. But this is beyond the point. It was suggested that running timers would prevent an app from finishing execution. If I don't care about what's done in the timer event during execution of my Form_Unload code, then it's not necessary to disable the Timer. BTW, I stated >> when you unload the form it is placed on IIRC, the docs say the form is unloaded _after_ execution of any code in the Form_Unload event. As an example: One of my apps displays the storage tanks of an icecream company. The timer kicks in every 20 seconds to retrieve weight and temperature of the icecream tanks and displays the tanks and the data on the screen. If the app shuts down, I don't care if the timer will kick in and display a last update or not. So Idon't disable the Timer control and the app shuts down nicely. To Larry: They can't talk about VB5, 'cause this app was written in VB5 and I finally upgraded it to VB6 in 2005. Helmut.
From: MikeD on 6 Apr 2010 16:20 "Helmut Meukel" <NoSpam(a)NoProvider.de> wrote in message news:Ob2PUNa1KHA.2028(a)TK2MSFTNGP05.phx.gbl... > "mscir" <mscir(a)yahoo.com> schrieb im Newsbeitrag > news:hp6ahk$12m1$1(a)adenine.netfront.net... >> Also I've saved these over the years: >> >> 1------------------------------------------------------------------------ >> Subject: Re: Unload Form, Set Form=Nothing, End, program doesn't end! >> Date: Thu, 19 Mar 1998 17:34:52 -0500 >> From: "A Consultant" <consultant(a)towers.com> >> Newsgroups: microsoft.public.vb.general.discussion >> >> Make sure that you turn OFF all TIMER controls! Forms stay loaded if >> timers still active. > > As many suggestions made for avoiding End this one is plain wrong! > The Timer control that comes with VB6 is shut down automatically > when you unload the form it is placed on! > Naw, I can't agree with that statement hardly at all. Granted, what you say is true, but it's also true that the Timer control is not disabled until the form has COMPLETELY been destroyed. And invariably, the Timer control fires once more causing the form to either reload or prevents it from unloading due to the Timer event being on the stack. The shorter the timer's interval, the more likely you are to encounter this problem (but other factors are involved too). I consider it best practice to always explicitly disable Timer controls. At the very least, it certainly doesn't hurt anything whatsoever. -- Mike
From: MikeD on 6 Apr 2010 16:35
"Eduardo" <mm(a)mm.com> wrote in message news:hpg2ou$903$1(a)speranza.aioe.org... > I know of one case where End is justified: > > At the Form_load of the first form, when you don't have a Sub Main. > > Example: > > If App.PrevInstance Then End > > Of course, you could handle the same thing in a Sub Main, but If you don't > want a Sub Main for whatever reason, then you need to place an End at the > Form_Load to avoid displaying the form. I can't agree. As far as I'm concerned, End is NEVER justified. There are other ways, which you even mentioned. What you're doing is trying to justify making one mistake because of another mistake. <g> And even so, you *can* unload the form from the Load event (although I seem to recall VB5 but perhaps it was VB4 that would raise an error if you did this). Granted, I would not consider that good practice (if for no other reason than it's not logical to have loaded the form in the first place). If you're gonna check for a previous instance, doing so in Sub Main as the VERY FIRST thing should be considered a golden rule to follow. And regardless, if you've done anything PRIOR to checking PrevInstance, it may still need to be properly cleaned up or else you could have problems. If you're going to check for PrevInstance, you need to do that before you do ANYTHING else and that includes loading a form. To not do so is just sloppy programming. -- Mike |