If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

On 19 Jan 2003 15:26:22 -0800, Kent wrote:
> You make things seem as rosey as MM makes them seem bleak. As I recall early
> OCX controls sucked bigtime! Also, you weren't forced into them right away,
> because the 16 bit version of VB still supported VBX files. I also remember
> the OLE runtime files being broken by new versions of office that came along.

There were problems with the first controls that companies released, as
there are with any v1.0 software, but the point is that architecture of OCX
controls was so much better than that of VBX and provided far more
stability than we were used to. With the new versions of controls came
loads of new features, so most people were very happy (except Mike of
course )
> And for those of us who actually built the controls it was even worse. That
> is until 1996 when the spec was "simplified"
>
> You shouldn't judge people so quickly, you've made a few statements of your
> own that are questionable.

Judge people quickly? I've had years of Mike's messages to judge him by
Of course I've made questionable statements, every comment is questionable,
and I'm happy for people to point out where I might have missed or
misunderstood something. There are often viewpoints that are not considered
by a poster, which is why it's important to keep an open mind and impartial
attitude.

Mike Mitchell <kylix_is@yahoo.co.uk> wrote:
>On Fri, 24 Jan 2003 15:21:56 -0500, "Larry Triezenberg"
><ltriezenberg@pathsys.com> wrote:
>
>>..... That
>>raises the bar much higher than just taking a couple of weeks to upgrade
and
>>being able to move on into taking advantage of some of the new features.
>
>And that is the big difference between *all* previous VB upgrades and
>the upgrade from VB to VB.Net. In *all* previous upgrades you didn't
>need to rewrite the app. Sure, you may have had to make minor mods,
>but in general the "old" version loaded straight into the upgrade, and
>you were away! Up and running.
>
>You see, Paul, the thing is, bringing out a new programming system
>like VB was in 1991 should be like a marriage, especially given that
>one of the parties was Microsoft, the biggest software company in the
>world that knew then that it wanted and aspired to ruling the world,
>software-wise at least. When such a company with hegemonic tendencies
>brings out a new product, it should make its vows to the world in
>promising to keep that product around forever, if need be. Not a
>ten-year fling and then, hey, let's go for the younger model! And
>leave the old VB with 3 million screaming kids in tow and not much of
>a contract left (let's just hang on for euthanasia in 2008 is not much
>of a contract, is it?).
>
>It may end up like lots of real marriages that only really stay
>together because of the kids. But I happen to think that the kids in
>any marriage are kinda important and that's why, in the real world, we
>have marriage guidance counsellors, child support agencies, indeed, a
>whole plethora of support to try and keep that compact between church
>and state - or between Microsoft and The People - functioning for as
>long as human(e)ly possible. By unceremoniously killing off real VB
>for its replacement product, the kids are now wandering the streets,
>looking for places to hang out. Getting into all kinds of scrapes with
>dodgy strangers. Is this what you'd want for your kids, eh?
>
>Let's hope, for VB.Netizens' sake, that VB.Net doesn't get the
>unceremonious coup de grāce at some point in the future. It's unfair
>of a company not to have done its sums beforehand and then simply take
>it out on the faithful supporters whenever it likes. VB.Net should be
>here to stay. There has to be some sense of responsibility here, and
>not just to shareholders. I mean, don't we all want to go to heaven?
>
>MM

On Wed, 22 Jan 2003 15:15:22 -0600, Dan Barclay wrote:
> On Wed, 22 Jan 2003 14:19:34 -0600, Paul Clement
>>
>>I used it in old line coded basic, which had no Subs or Functions, but there was never any reason to
>>use it in QuickBASIC or any variant of the structured BASIC language. It is outdated just as GoTo
>>is.
>
> Oh, so GoTo is scheduled for removal? Didn't know that. I suppose it
> makes about as much sense though. I've been outta touch but I'm glad
> you're keeping up with 'em.

I also doubt if GoTo will be removed. The GoSub has almost direct
replacements, but GoTo doesn't, and there are sometimes situations where
GoTo gives enormous simplification (possibly at the expense of structure).
>>¤ Duplicate code fragments are a virus in code that lives through years
>>¤ of maintenance. It's a hard fact that, at some point, one copy of the
>>¤ fragment will be fixed or enhanced and others will be missed. Its
>>¤ proper usage is as a code-only container for eliminating duplicate
>>¤ code fragments.
>>
>>Problem is it isn't a container but a containee that affects the flow of logic within its container.
>
> Certainly it is a container, and it works quite well. You *really*
> should learn something about it.

Very arguable. It's not really a container, because it has no effect on
scope of variables. It is a flow control statement in the same manner as
GoTo, but we could all argue semantics...
The only advantage over a Subroutine is that it retains the scope of all
the variables that the calling function has.

Having said all this, there are situation where using GoSub would save time
and resources, particularly in large complex (spaghetti?) routines that
have not been broken into structured subroutines and using large numbers of
variables. It certainly is frequently a killer of readability and
maintainability, and I know that I won't miss it, but then that's just my
way of coding.