To End Or Not To End. But How To End
in [Visual Basic]
|
From: Karl E. Peterson on 6 Apr 2010 13:58 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. -- ..NET: It's About Trust! http://vfred.mvps.org
From: Karl E. Peterson on 6 Apr 2010 14:02 Helmut Meukel wrote: > So between VB-DOS and VB1 we lost the n% parameter, but VB did still all > necessary clean-up. Point of order. VBDOS actually came *after* VB1. But it did still retain the exitcode parameter so familiar to DOS junkies. Interesting addendum. To regain the exitcode capability, you essentially have to emulate END with a call to ExitProcess. <g> -- ..NET: It's About Trust! http://vfred.mvps.org
From: Mike B on 6 Apr 2010 15:05 "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 > -- > .NET: It's About Trust! > http://vfred.mvps.org > >
From: Karl E. Peterson on 6 Apr 2010 15:19 Mike B wrote: > "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 Yeah, I've been watching that with some amusement. Sure glad I learned my lesson long ago! -- ..NET: It's About Trust! http://vfred.mvps.org
From: Eduardo on 6 Apr 2010 15:41
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. You could also move the form out of the screen and then Unload it on other event such as the Form_Activate, but what is more "elegant"? I don't see any "evilness" in doing that. |