.NOT My Views

[Roger Rabbit]

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.



RR

 

[Roger Rabbit]

"And if you're developing a Windows GUI app today using Microsoft's
"official" latest-and-greatest Windows programming environment, WinForms,
you're going to have to start over again in two years to support Longhorn
and Avalon. Which explains why WinForms is completely stillborn. "

Ive read his article. Its a lot of fluff really. Its all ifs, maybes,
could-bes, might-bes and possiblies as per his opening paragraph.

"Microsoft is finished. As soon as Linux makes some inroads on the desktop
and web applications replace desktop applications, the mighty empire will
topple."

He subsequently suggests this is a bit far fetched but then goes on to use
the same of "if all these things were to happen then so would this" logic in
the remainder of the article. I dont buy it. More scare tactics if you ask
me.

We've been developing for .Net for 5 years now. If Vista comes out next
year, it will be six. I dont forsee a massive market share swing toward
Vista for many of the same reasons as posted in Joels article.

"Microsoft grew up during the 1980s and 1990s, when the growth in personal
computers was so dramatic that every year there were more new computers sold
than the entire installed base. That meant that if you made a product that
only worked on new computers, within a year or two it could take over the
world even if nobody switched to your product."

I dont anticipate the upgrade rates to be very high circa 2006 through to
2010. But the time Longhorn gets any serious kind of traction we'll have
been developing for .Net for 10 years. If after 10 years we need to upskill
into Avalon and Xaml then so be it, that's technology for you. In the
meantime we will have received all the productivity benefits of using .Net
framework and the CLR.

Besides according to the Op only the Indians will have to worry about any of
this before long anyhow.
;-)

RR

 

[Cor Ligthert [MVP]]

Ken,

What do you think that will happen when you give a user a program with a
loop in it, that waits some parts of a second.

A week later you give him a program in which you have shorten that delay
time and tell him that it was a lot of work, however you have improved it.

A month later you give him that again, with again a shorter delay.

Do you think that the user will recognise it.
He will probably only tell that the last one he got is very fast.

Just my thought in this (partial) thread between you and Karl,

Cor

 

[Cor Ligthert [MVP]]

Kevin,

Besides, I think the VB Classic MVP's have it right...by the time I
tortured myself into learning all that new syntax, M$ will replace .NET
with something else that will break my code yet a second time. I have
better things to do than to re-learn everything I've ever known because M$
thinks that's what it is our best interest.

I agree this with you. (I am surely not from the classic camp). Maybe should
Microsoft have given VBNet another name? Something as V# and let VB die
after its normal supported time and had given tools to convert it to V#. As
they did now to VBNet (although they call it now upgrading).

They did this with C++ and came with C#, (although without the converting
tools).

They did this not with VB, maybe for marketing reasons maybe because of
nostalgia. (Basic is very much related to Microsoft from the first start).
However that they have kept it as VB is history and as I wrote somewhere
else in this thread, you cannot change history.

Before you tell it, that they go on with C++ . That is in my opinion
reasonable. Because there is needed a language for more to the machine side
development, so that is for me a straight reason to keep that alive.

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'.

Just my opinion.

Cor

 

[Rick Rothstein [MVP - Visual Basic]]

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]]

So RR's point is clear. Compare 1 line of .net to 7 lines of vb6
code.

Oh God I always hated the "open ... for binary as #" hehehehe. What kind of
a syntax is it? .Net to the rescue.

The kind of syntax that it is is one in which my old project files
continued to load no matter the newer version of VB (.NET excluded
of course), could be improved and recompiled without a second's
thought. For those with legacy projects, trust me, .NET has NOT
come to the rescue.

Rick

 

[Gary Nelson]

RR,

But then again you could do it this way:

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

Function ReadAllText(FileName as string) as string
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
ReadAllText = Contents
End Function

 

[J French]

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 nobody is going to wade through that, they write it once and
re-use it all the time

S$ = FileStr( "c:\mytextfile.txt" )

 

[Rick Rothstein [MVP - Visual Basic]]

and place it in a BAS Module along with all my other file

but how much of the functionality are you going to surround with function
calls and classes?

A lot less than 20 Megs worth.

And its you who is doing that, how are you going to make
this utility code available to all the vb6 devs?

Through these newsgroups as I have been doing for the last 6 years
or so.

.Net that makes it available for everyone.

But to move into your .NET world, I have to move my existing code
there too (assuming I will want to keep adding features to them).
Since Microsoft didn't provide an effective translator for the
job, I have to do it all myself. For the given example, I have to
find all of the projects using the function I currently use to
read in a text file and replace them with your line of code. And
that is just ONE change I would have to do. The time and effort to
move my legacy code to .NET appears to be substantial.


Rick

 

[Gary Nelson]

RR,

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

I see you are using VB 2005 which is still in Beta at this time...

Just an anecdote from my personal experience:

I've been working for over two years on a project in Asp.net (a Spanish
accounting program, you can visit it at www.conta.net - if you understand
Spanish). Anyway, in July I was attending TechEd 2005 in Amsterdam and they
were going on about all these wild and worderful new things that VS2005
does. So, I thought, why not give it a go. Now I must say that I am not at
all ignorant of the dangers of installing a Beta product. I got very badly
burned by the VB5CCE Beta, and I remember that at the time MS wouldn't even
say they were sorry after blowing up many developers VB4 production
machines. They said that it was understood that you don't install Beta
software on a production machine. But, to continue on with my story, I was
in Amstertam, I had my trusty production machine with me, and I had made
backups of everything before leaving, and I was feeling like living
dangerously. I figured that in a worst case scenario, I could always just
format the HD and reinstall everything. So I pulled out the fresh new VS2005
Beta DVD, and let it roll on my HD. Then I loaded my project into VS2005 and
it asked if I wanted to upgrade, and of course I answered YES! By the way,
my project is not just an ordinary little project, it contains several
controls, DLLs and a web service. After grinding away for awhile it finally
came to a halt. Now, what were the results? Was I going to be able to do new
wild and wonderful things to my project? Unfortunately, but not
unexpectedly, no. The VS2005 Beta had blown my project to smitherines. It
would not load, it would not do anything. Not only that, but there was very
little recognizable about it. MS has not lost their touch! What I found
especially "cute" about their conversion mechanism, is that instead of
leaving the originaly project intact and creating a new project, they
overwrite the original source code, so that, if you haven't made a backup
copy they efectively exterminate your code. Since I was still in Amsterdam,
I took my production machine in the next day and visited the "Ask the
Experts" booth, to talk to the guy who had given the talk on upgrading to
VS2005. He spent about half an hour looking at it and finally admitted that
He didn't have any idea of what had happened.
So then I had to start manually copying each project back to the
original directories. I had to manually clean up the mess of files that
VS2005 had scattered around the HD. Then I spent several hours trying to get
my project to run again, to no avail. Finally I went into IIS and found that
the upgrader had messed up the IIS configuration settings. After that, my
ASP.NET 2003 project was finally back in working order.
What have I learned? Foremost and above all, MS has not learned any of
the lessons (as if I had expected them to). They will continue to break code
at willl. They are the 800lb. gorilla and they sit where they want and do
what they want and if you don't like it don't work with them.

Gary

 

[Gary Nelson]

Ab,

So RR's point is clear.

Not really.

Compare 1 line of .net to 7 lines of vb6 code.
Oh God I always hated the "open ... for binary as #" hehehehe. What kind
of
a syntax is it? .Net to the rescue.

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



Gary

 

[Cor Ligthert [MVP]]

Gary,

Despite that it was not in VB2003 starts VB2005 after that you have started
the project (which tells that you cannot use the official project anymore
after upgrading) for me with the question if I want to create an copy of
your VB2003 project and if I check the radio button for yes puts that in the
project map you choice as a backup.

I don't know if this was in the first Beta, which had very much warnings
around it not to use this on a production computer. This is with the RC1

I hope that it clears your message better and showed that in my opinion
Microsoft has learned something.

I hope this helps,

Cor

 

[Gary Nelson]

Cor,

Despite that it was not in VB2003 starts VB2005 after that you have
started the project (which tells that you cannot use the official project
anymore after upgrading) for me with the question if I want to create an
copy of your VB2003 project and if I check the radio button for yes puts
that in the project map you choice as a backup.

I've been programming for over twenty years, and one of the first things I
learned, many many years ago, is that you don't break peoples data. Sure,
they give me a radio button to make a backup copy, but I could care less
about that, I had already made a backup copy of everything before starting.

Is it really that hard to create a new project space and a new project and
leave my original project alone? I think not.

I don't know if this was in the first Beta, which had very much warnings
around it not to use this on a production computer. This is with the RC1

I don't know if you really read what I wrote. I was absolutely conscious of
the warnings and knew exactly what I was doing. By the way, it was not the
first Beta, it was the second Beta.

I hope that it clears your message better and showed that in my opinion
Microsoft has learned something.

In your opinion, what has Microsoft learned?

I hope this helps,

I don't think so.

Gary

 

[Roger Rabbit]

But then again you could do it this way:


The point is with dotNet "I" dont have to do anything. If your suggesting
the "My" namespace is just a series of wrapper functions then your
absolutely right (but then so is the whole framework) however the point is
that the plumbings been done for me.

When i move to the next ISV/hire someone for the current ISV we're all still
talking the same language. Its a framework construct not an ISV dependant
construct. No relearning required. Not only does the VB6 developer have to
write all that gunk in the first place but then they have to wrap it, test
it, maintain and deploy it.

For the .Net developer its just there and it works. What would be a breaking
change for VB6, might not be for .NET because its been abstracted away. If i
want to drill down and reinvent the wheel i can do that too.

How many more lines would this amount too?

Dim comport As IO.Ports.SerialPort
comport = My.Computer.Ports.OpenSerialPort("COM1")
AddHandler comport.ReceivedEvent, AddressOf DataReceived

VB6 just cant compete with this kind of power "out of the box". Every fresh
line of VB6 code you write is just digging yourself a deeper and deeper
hole. For your customers sake just "stop" already.



RR

 

[Roger Rabbit]

I see you are using VB 2005 which is still in Beta at this time...

Only for the next month or so.



RR

 

[Mike Williams]

In fact, a quick search will point you to a white paper showing
that the VB.Net compiled runtime is faster in addition &
subtraction than not only VB6 but also C#, C++

Salesmen have wet dreams about people like you ;-)

 

[Herfried K. Wagner [MVP]]

The whole point is he doesn't. Its been constantly suggested that unless
there is a very specific need there is no need to convert "legacy" code to
dotNet.

The main question is if this is possible if the runtime or one of the
library gets broken. There has already been a case where applications'
behavior has been altered by another version of a DLL.

<URL:http://classicvb.org/petition/faq.asp>
-> "VB6 still works; there's no reason in the world they can't just keep
using it."

 

[Herfried K. Wagner [MVP]]

How many lines of VB6 code would it takes to do this? And what would that
nasty ass bit of code look like?

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

A single line in VB6 too, assuming that one has alread implemented this
functionality /years/ ago in Microsoft Basic ;-).

 

[Herfried K. Wagner [MVP]]

Unlike VB6, VB.Net addition & subtraction
operations are extremely fast. In fact, a quick search will point you to
a
white paper

Could you point me to this white paper?

showing that the VB.Net compiled runtime is faster in addition &
subtraction than not only VB6 but also C#, C++ (pick your flavor), and of
course Java *note this holds true for .Net 1.0 & 1.1 - I havn't tested 2.0
yet but I would imagine the C# & C++ compilers are now using the same
optimizations*. I ORed in VB6 because there is no net gain to using
addition, I added in VB.Net because the gain is quite substantial.

There is no gain at all in the sample you showed. Combining the bitflags is
done at /compile time/.

 

[Gary Nelson]

RR,

VB6 just cant compete with this kind of power "out of the box". Every
fresh
line of VB6 code you write is just digging yourself a deeper and deeper
hole. For your customers sake just "stop" already.

You either:

1) don't have many customers
2) don't have much code

If you have hundreds of thousands of lines of legacy code and thousands of
customers, what you say is not posible for the following reasons:

Will customers who are demanding, and in cases have already paid for,
certain funcionality, be willing to wait for a year or two while you upgrade
to VB.Net?

Do you have deep enough pockets to pay wages to the employees while the
company brings out no new products and does no repair on the old as all of
the work force is converting to .net?

Gary