.NOT My Views

[Roger Rabbit]

Theres alot of things you dontNetters failed to notice... not the least of
which was the fact your dev platform was to become obsolete.



RR

 

[Karl E. Peterson]

Hi Cor --

I hope therefore that they will keep the language more cleanly and
only 'add' instead of changing all the time, however I am afraid they
do not.

One of the points that show this for me is that they have kept in the
new versions the 'Integer' 32bits and did not make it according to
the register size. This will mean again big changes in future when
everybody is forgotten this, while all things to do was already done
when there was the step from 16bits to 32bits. Probably most will
have called the fixed size needed 32Bit value now 'Int32'.

That's just a critical point, here, and needs to be highlighted. The MSBasic Integer
datatype was 16-bits from the CP/M days of 8-bit CPUs to the Win32 VB6 -- a full
quarter century covering the most explosive growth ever in the industry. Redefining
this fundamental datatype was akin to sacrilege. Something a langauge vendor simply
should *never* do! Microsoft supposedly understood this with the redefinition of
String at VB4, but here they are at it again.

Yes, I fully agree with you. I suspect it won't be that many years until Integer has
come to find itself being 64-bits long. "Need a new type of data? Create a new
datatype!" What's so difficult to understand about that? Why weren't Int16, Int32,
and Int64 sufficient for those worried about insuring the most performant code?

The trust is gone.

Thanks... Karl

 

[Karl E. Peterson]

All programmers like new functionality. The function RR is flouting
could have easily been added to VB without breaking compatibility
with VB6.

It was, actually.

But then, *most* Classic VB devs reject FSO for the abomination it is.

 

[Rick Rothstein [MVP - Visual Basic]]

So in a nutshell your resistant to change and just want things

to be the way they were.

No, I think you have completely misread the non-.NET desire. We
are not resistant to change, we just don't want to lose what we
had for the sake of that change. For VB's entire existence (the
non-VB.NET versions of VB that is), some 10 years of existence,
Microsoft managed to add functionalities and technologies to the
language without destroying old code from functioning (with maybe
one or two notable exceptions) and when code changes were
required, the changes were not huge and project destroying. Old
code could be brought forward into the newer versions of VB as
they were released. And trust me, I was delighted with all of the
new things added to VB with each version change (again, I am
talking of non-VB.NET here).

Rick

 

[Karl E. Peterson]

No, I think you have completely misread the non-.NET desire. We
are not resistant to change, we just don't want to lose what we
had for the sake of that change.

<spit>Gratuitous Incompatabilities</spit>

 

[Roger Rabbit]

http://www.fawcette.com/archives/premier/mgznarch/vbpj/1992/mayjun92/guest.pdf

Just like a VB6er to be quoting something someone said about technology 13
years ago.



Eyes on the prize Karl and the prize is the future.

RR

 

[Bob Butler]

http://www.fawcette.com/archives/premier/mgznarch/vbpj/1992/mayjun92/guest.pdf

Just like a VB6er to be quoting something someone said about
technology 13 years ago.

"Those who cannot remember the past are condemned to repeat it."
--George Santayana

You'll understand it someday. Until then, good luck. You'll need it.

 

[Kevin Provance]

I am not restistant to change, however not all change is good. Look at what
happened when Hitler came to power, look at what happened to America when
Bush came into the White House.

Sounds to me, based on this rather none-sensical reply that you are another
automaton that follows the crowd versus thinking for yourself. Hell, you
have to hide behind the name of a cartoon character rather than attaching a
real name to your persona (and consequently, earning the same reputation of
a cartoon character). Merely spewing back the same propoganda that MS has
installed into you under a false name does not an argument make. I am sure
you believe exactly what you are are saying, and more power to you. it
doesn't make you right. I'll concede the same thing and perhaps ion the end
we'll have to agree to disagree and leave it at that.

I am curious though, if you are married (or intend to marry) what will
happen to your wife when she gets old? Render her obsolete and get a newer
model? What is she gets fat and unattractive? Will you just throw her
away? What if you have kids and they turn out to be punks who embrace a
life of crime? Would you then render them obsolete? Based on your previous
post, it sounds exactly like something you would do. If after another few
years MS dumps .NET and forces you to move on to a new platform will you
simply toss away all your prior work simply to be part of the what you
perceive to be the "in" crowd to avoid being labeled obsolete?

I would rather be good at what I do even if it considered obsolete then be
half-assed at what whever "change" is thrust upon me...and could care less
what the in crowd thinks of me. Simply diving into the latest and greatest
offering does not make you intelligent, nor does it make you irreplaceable.
Some of the smartest and clever fellows I've met here, who could undoubtedly
pick up .NET in a fair amount of time simply refuse to do so because they
know it's pointless. They know MS's track record of rendering a perfectly
good language obsolete simply because they think the new way is better. New
does not equate to better, nor does all "change".

- Kev (a.k.a Yosemite Sam)

So in a nutshell your resistant to change and just want things to be the
way
they were.

That's fine. But its not realistic. I expect to turn my skillset over
every
5 years. That's the world we live in. Maybe last century you could get
away
with the same skillset for 20 plus years but that's not the case anymore.

I don't want a new marriage, I am

happy with the one I am in...and I certainly don't appreciate being told my
"children" are obsolete, along with my "wife" because they think the new
marriage would be better for me.

Well taking the emotive language out it I'm sure your actual wife and kids
are lovely...your programmatic wife and kids however are outdated and they
are obsolete. Monogamy in a technical sense is an outdated concept.

To survive in 21st Century development requires that you be a serial
polygamist. Its requires that you be a veritable Casanova of the
technological spectrum, that you bed many and wed none. While whispering
sweet nothings in the ear of your current Bo you are constantly looking
over
her shoulder for what's coming through the door. You need to stay virile
and
have a hunger and a passion for new conquests.

At the end of the day you don't slump on the couch with a bag of Cheetos
but
rather see this as the moment where the real work begins as you delve into
a
study of the fine art of tantric seduction.

The longer this thread runs the more obvious it becomes that the
dontNetter
crowd have are professionally jealous of us dotNetters. As we dotNetters
forge energetically on ahead, going where no VB developer has gone before,
you dontNetters are stuck on some lonely hill on a cold dark night staring
up at the stars with your short, nearsighted telescopes in your hands.

You dontNetters sound like you fell for your code base and now 10-15 years
later you're all frustrated that she's grown fat and ugly and no longer
puts
the way she used too. Meanwhile us dotNetters are gallivanting about the
Universe in our sleek new space ship, discovering all manner of strange
and
interesting alien lifeforms and gently putting them to work for us as we
deliver one stellar performance after another..... at warp speed i might
add.

The fact is the technological chicks really dig us dotNetters and our
flashy
Intergalactic ways and you dontNetters are more than just a little
scornful
about being trapped raking out the muck from your earth bound trenches.
Your
all something akin to the poor people who desperately try to convince
themselves that while the rich might be wealthy they aren't happy. Well
the
truth is for all the dontNetters out there and their moaning and griping
about their archaic platform, the fact remains that us dotNetters are the
future. And the future is bright.

RR

Well, the way I see it is thus: I would rather have my handy dandy class
files and bas files which I know work (and yes, I will give you that .NET
can do it in one lines, once all the new syntax has been learned, understood
and remembered)...BUT, when I compile my project and create my setup
files
which include the VB runtimes...the download for the end user is still much
smaller than shipping out some .NET nightmare. The problem is this, and has
been mentioned: The .NET runtime is massive. In my 10+ years of dealing
with end users and their fickle systems, it was always to my advantage to
include the VB runtimes in my setup files, because when VB six was first
introduced, DLL Hell plauged my life with "OLE files out of date" messages.
I could not depend on my end users to have the current VB runtimes on their
computer...and I certianly could not depend on them always haveing the
latest SP's or Windows updates installed. And when I say I've dealt with
tens of thousands of people over the last ten years, I am not exaggerating.
I managed to curb the problem by always shipping the VB runtimes in my
setups with the versions instlled with VS6 and some competent version
checking in my setups. Problems mostly solved.

Now, taking all that into consideration with .NET, I would have to
include
the .NET runtimes in my setup packages, which would create 20+ MB files for
the end user to download. Otherwise if I assumed the end users already had
the .NET runtimes installed, I would be spending ever waking hour with
support tickets over an installation process that should manage itself.

So, between having to learn a new lanaguage for all intents and purposes,
and then ensuring the end users have all the proper runtimes by including
those massive .NET runtime files...and not even mentioning how sluggish and
slow .NET compiled programs run in general...it just not worth it. M$
did
me a great disservice by throwing away VB classic along with everything I've
worked so hard for over the last ten years including code and protocols and
giving me .NET in return. And for what reason? Because they think it's
better? Again, I would rather have my BAS files with code I know works than
the so called convenience of only needing to type one line in .NET. It's
not a trade off I am willing to make, citing everything I've just explained.

If you want another analogy, consider the programs I've developed with my
marriage to VB 6 my "children". Now M$ has suggested I divorce from VB6 to
enter into another marriage with .NET. Good marriages take time and work
and don't always work out for the better. I don't want a new marriage, I am
happy with the one I am in...and I certainly don't appreciate being told my
"children" are obsolete, along with my "wife" because they think the new
marriage would be better for me. What made my marriage to VB 6 won't
work
for .NET. Plain and simple.

So, there it is. ;-)

- Kev

and place it in a BAS Module along with all my other file
manipulation Functions and Subs, then all I have to do is add that
Module to any projects needing file input and reduce the call to
this...

Content = ReadAllText("c:\temp\test.txt")

That really isn't such a burdensome thing to do.

but how much of the functionality are you going to surround with function
calls and classes? And its you who is doing that, how are you going to
make
this utility code available to all the vb6 devs? .Net that makes it
available for everyone.

Ab.



"Rick Rothstein [MVP - Visual Basic]"
<[email protected]>
wrote in message Well if you seriously prefer wading through this:

Dim FileNum As Long
Dim Contents As String
FileNum = FreeFile
Open "c:\mytextfile.txt" For Binary As #FileNum
Contents = Space(LOF(FileNum))
Get #FileNum, , Contents
Close #FileNum

as opposed to this:

Dim contents as string =
My.Computer.FileSystem.ReadAllText("c:\mytextfile.txt")

then we're never going to agree.

But if I bundle the code I posted up into a Function like this

Public Function ReadAllText(FileName As String) As String
Dim FileNum As Long
Dim Contents As String
FileNum = FreeFile
Open FileName For Binary As #FileNum
ReadAllText = Space(LOF(FileNum))
Get #FileNum, , ReadAllText
Close #FileNum
End Function

and place it in a BAS Module along with all my other file
manipulation Functions and Subs, then all I have to do is add that
Module to any projects needing file input and reduce the call to
this...

Content = ReadAllText("c:\temp\test.txt")

That really isn't such a burdensome thing to do.

Rick

 

[Kevin Provance]

C'mon now Karl, be fair. Not all of us "kids" are lazy tree sloths waiting
to be handed our program code on a silver framework. <g>

- Kev

 

[Kevin Provance]

The fact is the technological chicks really dig us dotNetters and ourIntergalactic ways and you dontNetters are more than just a little scornful
about being trapped raking out the muck from your earth bound trenches. <<

For what it's worth, I still drive around in a 1981 DeLorean, which by your
standards would be old and obsolete. However, it still get's me the chicks
and way more attention that the new and improved gas guzzling SUVs that were
once considered the future of automobiles.

Again, new is not always better. They call it "classic" for a reason. <g>

- Kev (who can do without the Back To The Future jokes)

 

[Kevin Provance]

Theres alot of things you dontNetters failed to notice... not the leastwhich was the fact your dev platform was to become obsolete. <<

On the contrary, I believe many of us, me included saw what was coming...and
how bad it was. It only made us do what do do better.



- Kev (campaigning for the dontNetter presidency)

 

[Roger Rabbit]

, however not all change is good. Look at what

happened when Hitler came to power, look at what happened to America when
Bush came into the White House.

Well ahmen to that.

I am curious though, if you are married (or intend to marry) what will
happen to your wife when she gets old? Render her obsolete and get a newer
model? What is she gets fat and unattractive? Will you just throw her
away? What if you have kids and they turn out to be punks who embrace a
life of crime? Would you then render them obsolete?

Theres a vast difference between a human being and a code base.

Based on your previous

post, it sounds exactly like something you would do. If after another few
years MS dumps .NET and forces you to move on to a new platform will you
simply toss away all your prior work simply to be part of the what you
perceive to be the "in" crowd to avoid being labeled obsolete?

Again with the victim mentality. Your not being forced to do anything. It
seems to me that your VB6ers are the one trying to force something out of
Microsoft.

I would rather be good at what I do even if it considered obsolete then be
half-assed at what whever "change" is thrust upon me...and could care less
what the in crowd thinks of me. Simply diving into the latest and greatest
offering does not make you intelligent, nor does it make you

irreplaceable.

And nor does going down with the ship make one courageous.

Some of the smartest and clever fellows I've met here, who could undoubtedly
pick up .NET in a fair amount of time simply refuse to do so because they
know it's pointless. They know MS's track record of rendering a perfectly
good language obsolete simply because they think the new way is better. New
does not equate to better, nor does all "change".

- Kev (a.k.a Yosemite Sam)

So in a nutshell your resistant to change and just want things to be the
way
they were.

That's fine. But its not realistic. I expect to turn my skillset over
every
5 years. That's the world we live in. Maybe last century you could get
away
with the same skillset for 20 plus years but that's not the case anymore.

I don't want a new marriage, I am

happy with the one I am in...and I certainly don't appreciate being

told
my

"children" are obsolete, along with my "wife" because they think the new
marriage would be better for me.

Well taking the emotive language out it I'm sure your actual wife and kids
are lovely...your programmatic wife and kids however are outdated and they
are obsolete. Monogamy in a technical sense is an outdated concept.

To survive in 21st Century development requires that you be a serial
polygamist. Its requires that you be a veritable Casanova of the
technological spectrum, that you bed many and wed none. While whispering
sweet nothings in the ear of your current Bo you are constantly looking
over
her shoulder for what's coming through the door. You need to stay virile
and
have a hunger and a passion for new conquests.

At the end of the day you don't slump on the couch with a bag of Cheetos
but
rather see this as the moment where the real work begins as you delve into
a
study of the fine art of tantric seduction.

The longer this thread runs the more obvious it becomes that the
dontNetter
crowd have are professionally jealous of us dotNetters. As we dotNetters
forge energetically on ahead, going where no VB developer has gone before,
you dontNetters are stuck on some lonely hill on a cold dark night staring
up at the stars with your short, nearsighted telescopes in your hands.

You dontNetters sound like you fell for your code base and now 10-15 years
later you're all frustrated that she's grown fat and ugly and no longer
puts
the way she used too. Meanwhile us dotNetters are gallivanting about the
Universe in our sleek new space ship, discovering all manner of strange
and
interesting alien lifeforms and gently putting them to work for us as we
deliver one stellar performance after another..... at warp speed i might
add.

The fact is the technological chicks really dig us dotNetters and our
flashy
Intergalactic ways and you dontNetters are more than just a little
scornful
about being trapped raking out the muck from your earth bound trenches.
Your
all something akin to the poor people who desperately try to convince
themselves that while the rich might be wealthy they aren't happy. Well
the
truth is for all the dontNetters out there and their moaning and griping
about their archaic platform, the fact remains that us dotNetters are the
future. And the future is bright.

RR

Well, the way I see it is thus: I would rather have my handy dandy class
files and bas files which I know work (and yes, I will give you that ..NET
can do it in one lines, once all the new syntax has been learned, understood
and remembered)...BUT, when I compile my project and create my setup
files
which include the VB runtimes...the download for the end user is still much
smaller than shipping out some .NET nightmare. The problem is this,

and
has

been mentioned: The .NET runtime is massive. In my 10+ years of dealing
with end users and their fickle systems, it was always to my advantage to
include the VB runtimes in my setup files, because when VB six was first
introduced, DLL Hell plauged my life with "OLE files out of date" messages.
I could not depend on my end users to have the current VB runtimes on their
computer...and I certianly could not depend on them always haveing the
latest SP's or Windows updates installed. And when I say I've dealt with
tens of thousands of people over the last ten years, I am not exaggerating.
I managed to curb the problem by always shipping the VB runtimes in my
setups with the versions instlled with VS6 and some competent version
checking in my setups. Problems mostly solved.

Now, taking all that into consideration with .NET, I would have to
include
the .NET runtimes in my setup packages, which would create 20+ MB files for
the end user to download. Otherwise if I assumed the end users already had
the .NET runtimes installed, I would be spending ever waking hour with
support tickets over an installation process that should manage itself.

So, between having to learn a new lanaguage for all intents and purposes,
and then ensuring the end users have all the proper runtimes by including
those massive .NET runtime files...and not even mentioning how sluggish and
slow .NET compiled programs run in general...it just not worth it. M$
did
me a great disservice by throwing away VB classic along with everything I've
worked so hard for over the last ten years including code and protocols and
giving me .NET in return. And for what reason? Because they think it's
better? Again, I would rather have my BAS files with code I know works than
the so called convenience of only needing to type one line in .NET. It's
not a trade off I am willing to make, citing everything I've just explained.

If you want another analogy, consider the programs I've developed with my
marriage to VB 6 my "children". Now M$ has suggested I divorce from

VB6
to

enter into another marriage with .NET. Good marriages take time and work
and don't always work out for the better. I don't want a new marriage,

I
am

happy with the one I am in...and I certainly don't appreciate being

told
my

"children" are obsolete, along with my "wife" because they think the new
marriage would be better for me. What made my marriage to VB 6 won't
work
for .NET. Plain and simple.

So, there it is. ;-)

- Kev

and place it in a BAS Module along with all my other file
manipulation Functions and Subs, then all I have to do is add that
Module to any projects needing file input and reduce the call to
this...

Content = ReadAllText("c:\temp\test.txt")

That really isn't such a burdensome thing to do.

but how much of the functionality are you going to surround with function
calls and classes? And its you who is doing that, how are you going to
make
this utility code available to all the vb6 devs? .Net that makes it
available for everyone.

Ab.



"Rick Rothstein [MVP - Visual Basic]"
<[email protected]>
wrote in message Well if you seriously prefer wading through this:

Dim FileNum As Long
Dim Contents As String
FileNum = FreeFile
Open "c:\mytextfile.txt" For Binary As #FileNum
Contents = Space(LOF(FileNum))
Get #FileNum, , Contents
Close #FileNum

as opposed to this:

Dim contents as string =
My.Computer.FileSystem.ReadAllText("c:\mytextfile.txt")

then we're never going to agree.

But if I bundle the code I posted up into a Function like this

Public Function ReadAllText(FileName As String) As String
Dim FileNum As Long
Dim Contents As String
FileNum = FreeFile
Open FileName For Binary As #FileNum
ReadAllText = Space(LOF(FileNum))
Get #FileNum, , ReadAllText
Close #FileNum
End Function

and place it in a BAS Module along with all my other file
manipulation Functions and Subs, then all I have to do is add that
Module to any projects needing file input and reduce the call to
this...

Content = ReadAllText("c:\temp\test.txt")

That really isn't such a burdensome thing to do.

Rick

 

[Roger Rabbit]

No, I think you have completely misread the non-.NET desire.

I dont think i have. You guys wanted a VB7 thats compatible with VB6 right?

VB.net is not VB6 plus 1. Its a completely different technology. The classic
VB is dead and petitions or not, its not coming back.
dontNetters can kick and scream all they like but its just not going to
happen. Its over. Its done.

Office 12/Sql Server /VS 2005/ Vista etc etc. I mean look around you. The
writings been on the wall since last century and its only gearing up not
slowing down. You all complain about bloated downloads/performance/etc etc
but frankly Microsoft is only just beginning to roll out dotNet. .Net to
date has been a hugely successful undertaking. You take the largest software
company in the world and make it stand on its end and move full steam ahead
45 degreees due East. The last 7 years have been about rebuilding a
platform.

Every software company in the world rolls out a working product and then
subsequently rolls out a more performant version of that product. For all
the VB6ers community complaining you seem to forget that VB6 was version 6.
..Net is version 1.1.

The VB6 argument is unrealistic in my opinion. VB6 was the wrong direction.
COM wasn't going to cut it. A new course had to be plotted and its as if
VB6ers expect everything to be perfect in getting there. dotNetters have
hitched their wagons to the framework. We knew there was going to be some
bumps in the road and we made contingencies for that. Now we're already
doing well but things are about to get even better. We're all skilled up and
ready to go and here we have the largest software company signalling that
between 2.0 and 3.0 one of the problems that they will be specifcally
addressing is the runtime distribution. They've been really busy with the
current roll out to date but now they realise its an issue that needs
addressing.

In the meantime heres a whole bunch more power in 2.0 to add to what we gave
you 1.1 plus not forgetting the worldclass compact, mobile, Webforms and
Webservices platforms which, if you didn't know already can be written using
precisely the same skillset you use in WinForms.

And then they say "oh by the way, you know software is only one half the
technological mix, the other being hardware? Well we've noticed that the
hardware can now do things that we're not able to tap into at present so
over the course of the next couple of years you might want to look into Xaml
for your presentation layers." So we say "yeah that makes sense lets have a
look at what their offering." A VB6er on the other hand will point to Avalon
and say "thats the sky is falling, Microsoft are doing a complete U-turn,
abandon ship, abandon ship". Its pathetic.

Alot of VB6ers will say "ive been doing this for 20 years, thats the way ive
always done it and by God thats the only way i want to do it." Well sorry
old man but that was yester-year. The fact is that change is the only
constant and a constant skillset revision is required if your products are
going to remain relevant.... and sometimes you need to close the door behind
you in order for another one to open.

Deprecations and code breakages are a good thing. They simplify the
platform. All this backwards compatible gunk while great for market share is
simply not sustainable. You end up with platforms that are a "jack of all
trades and a master of none."

RR

 

[Roger Rabbit]

Theres nothing lazy about avoiding redundancy. If you enjoy reinventing the
wheel then fair enough but some us prefer to build bikes.

RR

 

[Roger Rabbit]

Hell, you

have to hide behind the name of a cartoon character rather than attaching a
real name to your persona

The irony of course is that my real name is Thomas Jerry.

TJ

I am not restistant to change, however not all change is good. Look at what
happened when Hitler came to power, look at what happened to America when
Bush came into the White House.

Sounds to me, based on this rather none-sensical reply that you are another
automaton that follows the crowd versus thinking for yourself. Hell, you
have to hide behind the name of a cartoon character rather than attaching a
real name to your persona (and consequently, earning the same reputation of
a cartoon character). Merely spewing back the same propoganda that MS has
installed into you under a false name does not an argument make. I am sure
you believe exactly what you are are saying, and more power to you. it
doesn't make you right. I'll concede the same thing and perhaps ion the end
we'll have to agree to disagree and leave it at that.

I am curious though, if you are married (or intend to marry) what will
happen to your wife when she gets old? Render her obsolete and get a newer
model? What is she gets fat and unattractive? Will you just throw her
away? What if you have kids and they turn out to be punks who embrace a
life of crime? Would you then render them obsolete? Based on your previous
post, it sounds exactly like something you would do. If after another few
years MS dumps .NET and forces you to move on to a new platform will you
simply toss away all your prior work simply to be part of the what you
perceive to be the "in" crowd to avoid being labeled obsolete?

I would rather be good at what I do even if it considered obsolete then be
half-assed at what whever "change" is thrust upon me...and could care less
what the in crowd thinks of me. Simply diving into the latest and greatest
offering does not make you intelligent, nor does it make you irreplaceable.
Some of the smartest and clever fellows I've met here, who could undoubtedly
pick up .NET in a fair amount of time simply refuse to do so because they
know it's pointless. They know MS's track record of rendering a perfectly
good language obsolete simply because they think the new way is better. New
does not equate to better, nor does all "change".

- Kev (a.k.a Yosemite Sam)

So in a nutshell your resistant to change and just want things to be the
way
they were.

That's fine. But its not realistic. I expect to turn my skillset over
every
5 years. That's the world we live in. Maybe last century you could get
away
with the same skillset for 20 plus years but that's not the case anymore.

I don't want a new marriage, I am

happy with the one I am in...and I certainly don't appreciate being

told
my

"children" are obsolete, along with my "wife" because they think the new
marriage would be better for me.

Well taking the emotive language out it I'm sure your actual wife and kids
are lovely...your programmatic wife and kids however are outdated and they
are obsolete. Monogamy in a technical sense is an outdated concept.

To survive in 21st Century development requires that you be a serial
polygamist. Its requires that you be a veritable Casanova of the
technological spectrum, that you bed many and wed none. While whispering
sweet nothings in the ear of your current Bo you are constantly looking
over
her shoulder for what's coming through the door. You need to stay virile
and
have a hunger and a passion for new conquests.

At the end of the day you don't slump on the couch with a bag of Cheetos
but
rather see this as the moment where the real work begins as you delve into
a
study of the fine art of tantric seduction.

The longer this thread runs the more obvious it becomes that the
dontNetter
crowd have are professionally jealous of us dotNetters. As we dotNetters
forge energetically on ahead, going where no VB developer has gone before,
you dontNetters are stuck on some lonely hill on a cold dark night staring
up at the stars with your short, nearsighted telescopes in your hands.

You dontNetters sound like you fell for your code base and now 10-15 years
later you're all frustrated that she's grown fat and ugly and no longer
puts
the way she used too. Meanwhile us dotNetters are gallivanting about the
Universe in our sleek new space ship, discovering all manner of strange
and
interesting alien lifeforms and gently putting them to work for us as we
deliver one stellar performance after another..... at warp speed i might
add.

The fact is the technological chicks really dig us dotNetters and our
flashy
Intergalactic ways and you dontNetters are more than just a little
scornful
about being trapped raking out the muck from your earth bound trenches.
Your
all something akin to the poor people who desperately try to convince
themselves that while the rich might be wealthy they aren't happy. Well
the
truth is for all the dontNetters out there and their moaning and griping
about their archaic platform, the fact remains that us dotNetters are the
future. And the future is bright.

RR

Well, the way I see it is thus: I would rather have my handy dandy class
files and bas files which I know work (and yes, I will give you that ..NET
can do it in one lines, once all the new syntax has been learned, understood
and remembered)...BUT, when I compile my project and create my setup
files
which include the VB runtimes...the download for the end user is still much
smaller than shipping out some .NET nightmare. The problem is this,

and
has

been mentioned: The .NET runtime is massive. In my 10+ years of dealing
with end users and their fickle systems, it was always to my advantage to
include the VB runtimes in my setup files, because when VB six was first
introduced, DLL Hell plauged my life with "OLE files out of date" messages.
I could not depend on my end users to have the current VB runtimes on their
computer...and I certianly could not depend on them always haveing the
latest SP's or Windows updates installed. And when I say I've dealt with
tens of thousands of people over the last ten years, I am not exaggerating.
I managed to curb the problem by always shipping the VB runtimes in my
setups with the versions instlled with VS6 and some competent version
checking in my setups. Problems mostly solved.

Now, taking all that into consideration with .NET, I would have to
include
the .NET runtimes in my setup packages, which would create 20+ MB files for
the end user to download. Otherwise if I assumed the end users already had
the .NET runtimes installed, I would be spending ever waking hour with
support tickets over an installation process that should manage itself.

So, between having to learn a new lanaguage for all intents and purposes,
and then ensuring the end users have all the proper runtimes by including
those massive .NET runtime files...and not even mentioning how sluggish and
slow .NET compiled programs run in general...it just not worth it. M$
did
me a great disservice by throwing away VB classic along with everything I've
worked so hard for over the last ten years including code and protocols and
giving me .NET in return. And for what reason? Because they think it's
better? Again, I would rather have my BAS files with code I know works than
the so called convenience of only needing to type one line in .NET. It's
not a trade off I am willing to make, citing everything I've just explained.

If you want another analogy, consider the programs I've developed with my
marriage to VB 6 my "children". Now M$ has suggested I divorce from

VB6
to

enter into another marriage with .NET. Good marriages take time and work
and don't always work out for the better. I don't want a new marriage,

I
am

happy with the one I am in...and I certainly don't appreciate being

told
my

"children" are obsolete, along with my "wife" because they think the new
marriage would be better for me. What made my marriage to VB 6 won't
work
for .NET. Plain and simple.

So, there it is. ;-)

- Kev

and place it in a BAS Module along with all my other file
manipulation Functions and Subs, then all I have to do is add that
Module to any projects needing file input and reduce the call to
this...

Content = ReadAllText("c:\temp\test.txt")

That really isn't such a burdensome thing to do.

but how much of the functionality are you going to surround with function
calls and classes? And its you who is doing that, how are you going to
make
this utility code available to all the vb6 devs? .Net that makes it
available for everyone.

Ab.



"Rick Rothstein [MVP - Visual Basic]"
<[email protected]>
wrote in message Well if you seriously prefer wading through this:

Dim FileNum As Long
Dim Contents As String
FileNum = FreeFile
Open "c:\mytextfile.txt" For Binary As #FileNum
Contents = Space(LOF(FileNum))
Get #FileNum, , Contents
Close #FileNum

as opposed to this:

Dim contents as string =
My.Computer.FileSystem.ReadAllText("c:\mytextfile.txt")

then we're never going to agree.

But if I bundle the code I posted up into a Function like this

Public Function ReadAllText(FileName As String) As String
Dim FileNum As Long
Dim Contents As String
FileNum = FreeFile
Open FileName For Binary As #FileNum
ReadAllText = Space(LOF(FileNum))
Get #FileNum, , ReadAllText
Close #FileNum
End Function

and place it in a BAS Module along with all my other file
manipulation Functions and Subs, then all I have to do is add that
Module to any projects needing file input and reduce the call to
this...

Content = ReadAllText("c:\temp\test.txt")

That really isn't such a burdensome thing to do.

Rick

 

[Rick Rothstein [MVP - Visual Basic]]

Hell, you

than attaching
a

The irony of course is that my real name is Thomas Jerry.

Please tell me your middle initial is "N". <g>

Rick

 

[Ralph]

Hi Cor --


That's just a critical point, here, and needs to be highlighted. The MSBasic Integer
datatype was 16-bits from the CP/M days of 8-bit CPUs to the Win32 VB6 -- a full
quarter century covering the most explosive growth ever in the industry. Redefining
this fundamental datatype was akin to sacrilege. Something a langauge vendor simply
should *never* do! Microsoft supposedly understood this with the redefinition of
String at VB4, but here they are at it again.

Yes, I fully agree with you. I suspect it won't be that many years until Integer has
come to find itself being 64-bits long. "Need a new type of data? Create a new
datatype!" What's so difficult to understand about that? Why weren't Int16, Int32,
and Int64 sufficient for those worried about insuring the most performant code?

The trust is gone.

Thanks... Karl

The 'int' was defined in C as reflecting the natural size of integers on the
host machine. It was designed to be essentially 'sizeless' so that code
would be portable yet optimized. This was very important when working with
APIs. As almost all OSs were written with C the practice spread. (ASM has
its own 'integral' datatype, which also varies.)

When size mattered other datatypes were available - short, long, long long,
.... C programmers know you take the size of an int for granted at your
peril.

VB's 'Integer' was a specifically sized creature. In hindsight MS would have
been better off to have allowed it to 'grow' with the platform when VB4 came
along. They didn't. So I for one don't see that as a particular problem that
it has changed size in .Net. VBers should never have been dependent on the
size of the thing anyway, but VBers aren't C programmers, and were never
taught otherwise.

[As an aside: you forgot a couple, the __int36 on Honeywells, and the
__int24 on TechDatas. <g>]

-ralph

 

[Roger Rabbit]

Alas no. Wouldn't that be something?
Although my brother got Nigel.

TJ

 

[Gary Nelson]

Roger,

Or maybe (3) we do but we just handle them better than your company did.
The world is full of options why restrict the possibilites to just those
2.

That would be interesting to see...

I get the feeling that you don't read the posts you are responding to. Who

Its called cost benefit Gary whereby the benefit of the upgrade outweighs
the cost of the upgrade. An "investment" if you will. Another way to look
at
it is opportunity cost. Who pays for it? You do.

Now you're getting the idea.

If you cant justify the
cost then you "dont" upgrade. If there is no ROI then you dont invest. Its
quite simple.

That is exactly the problem. We can't make the transition to .NET because of
the ROI. It has nothing to do with tecnology and everything to do with
economics.

Again with this all or nothing argument. I assume you have some kind of
structure to your exisiting code base. You examine this for opportunities
where dotNet has some projected value. You then replace this segment of
your
code base. Your overly dramatic assertion about having to close the
doors/get everyone to retrain and rebuild is childish. If thats the
predicament you find yourself in then blame your architect(s) not
Microsoft.

By the way, Roger, to avoid going around in circles with useless arguments:
How much code have you actually written in VB6 and in .NET? I have been
programming in VB since version 1991 (version 1) and have been programming
in .NET for the last three years. I have easily got 150,000 lines of code in
VB6 right now, and probably about 30,000 in ASP.NET (VB). The problem is not
knowinig how to do it, Roger, it's the ROI.

As for the new development/these products your customers are clamouring for
/ you would use dotNet and interOp where neccessary. Your forms
issue/controls arrays wouldn't then be a problem because your not
converting
anything but adding value from scratch.

????

Have you ever even tried something like you are talking about? Have you
actually got a large project running on interOp?

If your company's on the bones of its arse and unable to reinvest in
itself
then thats a difficult situation but how does that get to be Microsofts
fault?

Roger, if I treated my custumers the way Microsoft has treated me, making a
mess of their data and making them reintroduce most of it I would soon be
without customers. But then I'm not an 800 lb. Gorilla.

The writing has been on the wall for a very long time. If your
company didn;t read it and now find yourself stuck in a quagmire of legacy
code then thats just poor business planning.

What writing? You obviously have not been in the business very long. Just as
an example, could you show me a cite of where it was announced (long before
..NET) that control arrays would be eliminated from .NET?

Gary

 

[Gary Nelson]

Herfried?

Yes. Simply open the project in VB 2005 and compile. Unfortunately some
of the APIs like 'System.Web.Mail' have been deprecated, but the code
should still compile and work.

Have you actually done that?

In my case I converted a ASP.NET 2003 project to ASP.NET 2005 and it just
went to pieces. Hundreds of errors appeared. It wouldn't even let me hit F8.
After messing with it for a couple of hours I decided that BETA2 just didn't
make the grade and went back to ASP.NET 2003. I'll try again when the final
version comes out, but I'm not very convinced that Microsoft has got the
idea ...

Gary