.NOT My Views

[Gary Nelson]

Karl,

It was, actually.

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

True. As a fact I've never used FSO. I looked at it once and that was about
it.

Gary

 

[Gary Nelson]

Ralph,

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.

Suppose you want to read a 16 bit integer value from a binary file, how do
you do that without depending on the size of the integer?

Gary

 

[Gary Nelson]

Roger,

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

Not exactly...

That's fine. But its not realistic. I expect to turn my skillset over
every
5 years.

Once you have actually written some code, and had it tosed out the window
every five years for a couple of times, you can come back and give us some
lessons.

Gary

 

[J French]

On Tue, 11 Oct 2005 16:02:29 +0200, "Cor Ligthert [MVP]"

Your part about whale oil let me think on this company

They improve the way they create their product all the time, do you think
that soap is made now on the same machine as it was in 1884.

Unilever's success is partly due to the dual listing that makes it
less vulnerable to predators
- that in turn allows it to take rational decisions

However, it is currently off loading its frozen food business, and it
is rumoured that its dual listing will be changed
- to me that is writing on the wall

Quite often companies get into trouble when they introduce new
technology or re-gear their business to different markets

There is also 'the Young Turk' cycle, where enthusiastic youngsters
make the same mistakes as their predecessors - because the corporate
memory has got lost.

 

[Cor Ligthert [MVP]]

Kevin,

Most of your text (I readed it completely) is in my opinion because as you
wrote not know well .Net

They are comfortable with what they have because it works for them and
their simpler needs.

This text I have seen more in history, it was never true that they did not
take the step, it is a push for the lazy ones.

However, the ammount of money involved with this is for almost not any
Western (including countries as China etc) business a problem. They are
often happy that they have a reason to take the step.

Just my thought,

Cor

 

[Frank Rizzo]

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")

Roger,

You are being dishonest. Why don't you post the code to do the
equivalent in the currently shipping version of VS.NET (which is v.2003)
and then will see if your solution is still straightforward and simple.

Ah, I'll tell you what, let me do it for you:

Dim oFile As FileStream = New FileStream(sFileName, FileMode.Open,
FileAccess.Read, FileShare.Read)
Dim oReader As StreamReader = New StreamReader(oFile)

Dim s As String = oReader.ReadToEnd

oReader.Close()
oFile.Close()


Still simple? I didn't think so.

 

[Cor Ligthert [MVP]]

Quite often companies get into trouble when they introduce new
technology or re-gear their business to different markets

There is also 'the Young Turk' cycle, where enthusiastic youngsters
make the same mistakes as their predecessors - because the corporate
memory has got lost.

Yes completely true, that is in most of the business.

AFAIK has only IBM a strategy with their mainframe OSes to keep it able to
let very old programs run.

However don't ask how much it cost to keep a mainframe up comparing to a
microprocessor computer.

However, that is AFAIK even not the fact at IBM with their development
tools.

The stronger survives, and in those cultures where that was protected in
history, did the stronger survive.

Just my thought,

Cor

 

[Cor Ligthert [MVP]]

Frank,

Dim oFile As FileStream = New FileStream(sFileName, FileMode.Open,
FileAccess.Read, FileShare.Read)
Dim oReader As StreamReader = New StreamReader(oFile)

Dim s As String = oReader.ReadToEnd

oReader.Close()
oFile.Close()

What you want to fullfil extra with this code beside the simple

\\\
Dim sr As New StreamReader(Path)
dim myText = sr.ReadToEnd
sr.Close
///

I am just curious about the purpose of all that code

Cor

 

[J French]

Yes completely true, that is in most of the business.

AFAIK has only IBM a strategy with their mainframe OSes to keep it able to
let very old programs run.

However don't ask how much it cost to keep a mainframe up comparing to a
microprocessor computer.

However, that is AFAIK even not the fact at IBM with their development
tools.

The stronger survives, and in those cultures where that was protected in
history, did the stronger survive.

Sometimes it is hard to work out what is the 'stronger' without the
benefit of hindsight.

At first a lot of people thought that PCs were a joke ...

 

[J French]

Kevin,

Most of your text (I readed it completely) is in my opinion because as you
wrote not know well .Net

This text I have seen more in history, it was never true that they did not
take the step, it is a push for the lazy ones.

However, the ammount of money involved with this is for almost not any
Western (including countries as China etc) business a problem. They are
often happy that they have a reason to take the step.

Very often companies buy into the 'cutting edge' stuff without knowing
what they are letting themselves in for.

 

[J French]

Ralph,

Suppose you want to read a 16 bit integer value from a binary file, how do
you do that without depending on the size of the integer?

Although what Ralph said about 'Integers' is true in theory, in
practice C programmers know all about the size of their 'Integers'

True portability is a myth, unless one rigorously sticks to ANSI
standards.

Redefining the Integer was no big deal for C programmers as unlike VB
thay have a whole slew of variables

 

[Herfried K. Wagner [MVP]]

Dim oFile As FileStream = New FileStream(sFileName, FileMode.Open,
FileAccess.Read, FileShare.Read)
Dim oReader As StreamReader = New StreamReader(oFile)

Dim s As String = oReader.ReadToEnd

oReader.Close()
oFile.Close()

In addition to the other replies: You don't need to close the stream
explicitly, it gets closed automatically if the stream reader is closed.
However, taking into account that the VB.NET solution requires an 'Imports'
statement too, the VB6 solution using FSO is not significantly longer:

\\\
Dim fso As FileSystemObject
Set fso = New FileSystemObject
Dim t As TextStream
Set t = fso.OpenTextFile("C:\WINDOWS\WIN.INI", ForReading)
Call MsgBox(t.ReadAll())
Call t.Close
///

When working with a fixed file number, the VB6 solution is even shorter:

\\\
Open "C:\WINDOWS\WIN.INI" For Input As #1
Call MsgBox(Input(LOF(1), #1))
Close #1
///

 

[Herfried K. Wagner [MVP]]

Have you actually done that?

In my case I converted a ASP.NET 2003

Mhm... I have rarely touched ASP.NET, so I am not able to confirm that. I
assume that the language remained stable but technologies changed.

 

[Herfried K. Wagner [MVP]]

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.

With appropriate IntelliSense support (which has not been present in VB6)
'Open' et al. would have been very easy to use.

 

[Herfried K. Wagner [MVP]]

Deprecations and code breakages are a good thing.

LOL! It really seems that you don't have any assets in Classic VB code.
Deprecations and code breakages are the /worst/ thing that can happen, both
from a technical and economical perspective. The fewer deprecations and
code breakages happen in a certain system, the better it has been designed.
Take the 'System.Web.Mail' namespace of the .NET Framework for example.
This namespace is four years old and has been deprecated, which shows that
it has been designed in a sloppy manner. There are thousands of
applications which rely on this namespace, and customers have invested in
code which is based on this namespace. It's legitimate to suspect that
development of a certain feature is not cancelled after a few years.

 

[Al Reid]

LOL! It really seems that you don't have any assets in Classic VB code.
Deprecations and code breakages are the /worst/ thing that can happen, both
from a technical and economical perspective. The fewer deprecations and
code breakages happen in a certain system, the better it has been designed.
Take the 'System.Web.Mail' namespace of the .NET Framework for example.
This namespace is four years old and has been deprecated, which shows that
it has been designed in a sloppy manner. There are thousands of
applications which rely on this namespace, and customers have invested in
code which is based on this namespace. It's legitimate to suspect that
development of a certain feature is not cancelled after a few years.

Herfried,

You seem to be one of the few regulars to the .Net NG that really understands the issues involved in the VB Classic vs. VB.Net
debate. It's not that the new .Net framework isn't the cats meow, its that it is difficult, at a minimum, to port existing projects
forward. It's not that "we" Classic VBers don't want to learn something new or are lazy. Nothing could be further from the truth.
Hell, I just created a VB.NET multithreaded windows service that mirrors directories across a network in a fraction of the time and
effort that it would have taken to do it in Classic VB. But that does nothing for me with respect to moving existing large VB
applications to the currently supported platform. Hell, all of the APIs and SDKs that I need to work with are COM based anyhow.
DotNet just wants to build a interop wrapper around it and sometimes it doesn't seem to work or seems sluggish. Porting
applications with custom ActiveX controls also seems to be somewhat hit or miss as well. MS seems to have just decided that my
existing code assets are not valuable.

Perhaps it will all become moot when MS releases VB9.0 along with a true upgrade wizard. <vbg>

 

[Sheldon Rosenfeld]

LOL! It really seems that you don't have any assets in Classic VB code.

Still searching for "Deprecations and code breakages" to C++.

What??? MS wouldn't do it as it would *BREAK* Office?
Come on!!! Re-write & re-test like the VB'ers!

 

[Ralph]

Although what Ralph said about 'Integers' is true in theory, in
practice C programmers know all about the size of their 'Integers'

True portability is a myth, unless one rigorously sticks to ANSI
standards.

Redefining the Integer was no big deal for C programmers as unlike VB
thay have a whole slew of variables

Just to nitpick - it isn't a matter of theory, it is a practical adaptation
to hardware variations. And the "int" is never 'redefined', but a slew of
specific types with defined sizes are created and are availble. [int is an
ANSI standard]

But Karl does have a point - the "Integer" in VBc is not an "int" it is a
16-bit signed thingy. Had they allowed the Integer to 'float' with VB4, they
would have had to add a new data type. MS chose not to, so they stuck with
keeping an Integer a 'short'. With a 64-bit 'intergral data type' on the
horizon, they would have had to do something, anyway, had VBc stayed in
existence.

To be fair to Karl, and to maintain true VBness, the "Integer" should
probably have remained 16-bit. A Long 32-bit, and they could have come up
with something new for a 64-bit thingy. Perhaps a 'Fred'. <g>

-ralph

 

[Ralph]

Ralph,


Suppose you want to read a 16 bit integer value from a binary file, how do
you do that without depending on the size of the integer?

Gary

I would probably use a WORD. Then I could extract LOBYTE and HIBYTE as
needed. <g>

"typedef unsigned short WORD;"

Oh, you mean in VB! <g> Then you have a rather limited choice - which was my
point.

-ralph

 

[Ken Halter]

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

RR

You mean 'redundancy' as in having to rewrite code just because a new toy
was released? There's no re-inventing a wheel that doesn't need to be
changed in the first place, eh?

Your "build bikes" statement directly conflicts with your "with dotNet 'I'
dont have to do anything" statement.

I do agree with you on one thing though.... the guy that started this thread
and crossposted to VB/B# groups in hopes of starting a thread like this, is
a troll.