Re: Microsoft's C++ bigotry
Date: Mon, 20 Jan 2003 12:26:35 +1100
User-Agent: 40tude_Dialog/18.104.22.168 (bba1155f.25.503)
X-Trace: 19 Jan 2003 17:13:28 -0800, c16664.brasd1.vic.optusnet.com.au
Xref: dnews vb.dotnet.discussion:48836
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
Re: Microsoft's C++ bigotry
Date: Thu, 23 Jan 2003 09:07:37 +1100
User-Agent: 40tude_Dialog/22.214.171.124 (d6d96615.16.510)
X-Trace: 22 Jan 2003 13:54:20 -0800, c16664.brasd1.vic.optusnet.com.au
Xref: dnews vb.dotnet.discussion:49015
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
> 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.
Re: Microsoft's C++ bigotry
Date: 25 Jan 2003 13:18:13 -0800
X-Trace: 25 Jan 2003 13:18:13 -0800, 127.0.0.1
Xref: dnews vb.dotnet.discussion:49245
You are mistaken. VBDOS and VB for Windows had *hundreds* of incompatibilies....everything
from missing or changed keywords....
ALL INKEY$ SEEKEQ
BLOAD INP SEEKGE
BOF INSERT SEEKGT
BSAVE IOCTL SEG
CALLS IOCTL$ SETINDEX
CDECL ISAM SETMEM
CHAIN KEY SETUEVENT
CHECKPOINT LIST SIGNAL
COLOR LOCATE SLEEP
COM LPOS SOUND
COMMON LPRINT SSEG
CREATEINDEX MKC$ SSEGADD
CSRLIN MKDMBF$ STACK
CVI MKI$ STICK
CVC MKL$ STRIG
CVD MKS$ SWAP
CVDMBF MKSMBF$ SYSTEM
CVL OUT TEXTCOMP
CVS PAINT TRON
CVSMBF PALETTE TROFF
DELETEINDEX PCOPY UEVENT
DELETETABLE PEEK UPDATE
DRAW PEN VARPTR
ERDEV PLAY VARPTR$
ERDEV$ PMAP VARSEG
EVENT POS VIEW
FIELD PRESET WAIT
FILES RUN WINDOW
to incompatible file formats. If you don't believe me, just check out the
following article and see it for yourself...
It's the platform, stupid.
Mike Mitchell <firstname.lastname@example.org> wrote:
>On Fri, 24 Jan 2003 15:21:56 -0500, "Larry Triezenberg"
>>raises the bar much higher than just taking a couple of weeks to upgrade
>>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?