.NOT My Views

[Gary Nelson]

RR,

Only for the next month or so.

Any idea if the upgrade from VS2003 to VS2005 is any easier than VB6 to
VB.Net?

My code sure didn't make the grade, and this time they don't even give you
the nifty 'ToDo


Gary

 

[Cor Ligthert [MVP]]

Gary,

Any idea if the upgrade from VS2003 to VS2005 is any easier than VB6 to
VB.Net?

If you don't want direct use all the new parts, than my expirience now is
that you will almost not notice it and is the same as from 2002 to 2003
(except for a lot of warnings which sometimes probably will be discussed in
future that they are overdone if they stay).

By instance this will give you in the last version a warning that a is not
assigned. (It is not actually how I do it, however I have seen this many
times done in this way).

\\\
private function bla(byval b as integer) as string
dim a as string
if b =1 then
a = 2
return a
else
return ""
end if
end function
///

I hope that this gives an idea.

Cor

 

[Roger Rabbit]

You can interOp between VB.net and VB6. This argument from VB6ers about
having to convert everything before being able to take advantage of the
power of the dotNet platform is just plain idiotic. Maintain existing code
in VB6. Look for opportunities to leverage .Net for new functionality.
Instead many VB6ers respond that if they cant have it all .NET then they
wont have any of it at all. All the while complaining that Microsoft is
abandoning them.

On the one hand you guys say "we cant upgrade because we have too much
code". So some one says "hey here's how dotNet can reduce the amount of code
you have to write, maintain and deploy", and you guys respond... "we cant
use that because we've got too much code?"

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?

Again with the conversion argument. How many times does it have to be said
"If you can't justify it then don't"? Its not mandatory.
But if your going to bring out new products in VB6 then you're the master
of your own demise and that's hardly Microsofts' fault.

RR

 

[jameshamilton777]

Um, I think Roger Rabbit should be called Roger Troll - not sure he
can be serious.

The person appears to be a "techie" computing student with no business
skills.
No-one who worked at a successfull ISV would be using .NET, especially
Beta software.
ISV implies downloading commerical type apps.
They would simply go out of business, no-one would download their
bloated grindware.

 

[J French]

Looks like we need a 'Bunny Boiler' round here

Preferably one that specializes in 'kittens'

 

[Cor Ligthert [MVP]]

James,

Um, I think Roger Rabbit should be called Roger Troll - not sure he
can be serious.

The person appears to be a "techie" computing student with no business
skills.
No-one who worked at a successfull ISV would be using .NET, especially
Beta software.
ISV implies downloading commerical type apps.
They would simply go out of business, no-one would download their
bloated grindware.

No one can be as good as you and have your experience, however still they
are allowed to give their opinion in these newsgroups and to be threaten
seriously.

If you think that it is a troll, do us than a favour, don't feed him.

Just my opinion.

Cor

 

[Ralph]

RR,


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

Unfortunately, one who does have:
1) Many customers
2) Much code
.... will have to do something, or otherwise adjust to decreasing sales while
creating an exit plan for closing their doors. The issues are little
different from what whale oil merchants and widget manufacturers have had to
address.

While we can complain that in this case it appears less 'natural' forces at
work than the capricious whim of a corporation, the effect is the same.

I am not surprised at the clumsy bravado of the dotnet adaptors and their
inability to recognize nor appreciate the plight of those with a investment.
How can they?

I am not surprised at the vehemence expressed by those who feel shafted. I
too am annoyed. But I am surprised that there are not more newsgroups, more
discussions, more articles, and more sharing in general of what a
company/developer can do to adjust to the new world order.

All of your questions are quite legitimate. Rather than have your post
blasted as an archaic view. I would like to see some of these dotnetters,
who had/have a VBc investment, and who has made the adjustment, explain how
they did it.

So far, with my limited experience of ~10 companies - very costly, total
immersion, has been the only successful way. Is that true?

-ralph

 

[Cor Ligthert [MVP]]

... will have to do something, or otherwise adjust to decreasing sales

while
creating an exit plan for closing their doors. The issues are little
different from what whale oil merchants and widget manufacturers have had
to
address.

Your part about whale oil let me think on this company

http://www.unilever.com/ourcompany/aboutunilever/history/1910s.asp

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.



Cor

 

[Herfried K. Wagner [MVP]]

Any idea if the upgrade from VS2003 to VS2005 is any easier than VB6 to
VB.Net?

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.

 

[Someone]

Off topic...

Abubakar,

Please adjust your time zone. Your computer seems to be set to Bill Gates'
time zone, PST, which is the default in Windows. While your local time
appears correct, your posts appear on the top in newsgroups(in the future)
and would cause time zone differences when you exchange files with a
computer that is set to a different time zone. Files dates and times are
adjusted when you copy files back and forth...

Thank you...

 

[Paul Clement]

On Tue, 11 Oct 2005 03:19:22 -0400, "Rick Rothstein [MVP - Visual Basic]"

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

No, just totally unnecessary in comparison. ;-)

Now just repeat that for every instance where one or two lines of code in VB.NET would suffice and
you'll find out how much time you've wasted.


Paul
~~~~
Microsoft MVP (Visual Basic)

 

[Rick Rothstein [MVP - Visual Basic]]

¤ 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

No, just totally unnecessary in comparison. ;-)

Now just repeat that for every instance where one or two lines

of code in VB.NET would suffice and

you'll find out how much time you've wasted.

I look at this differently.. How much time am I going to have to
waste finding out all of these equivalent lines of code to replace
the function library I have already built up over the last 8+
years of VB5/6 programming (all of which work fine and all of
which probably need to be replaced)? And, of course, this doesn't
include having to learn the new VB.NET language on top of that
(something I didn't have to do when moving from VB3 to VB4, VB4 to
VB5 nor VB5 to VB6).

Rick

 

[Ken Halter]

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

That would've been perfect. New language, new name. Period. B# would've been
perfect. No put down, no bull. Just a new name for a new language.

.....and that snip that reads files that people are having a hard time
"wading" through works fine in >all< versions of VB and most versions of DOS
Basic. In other words, the snip may've been written in the 1980's and still
work perfectly fine now.

All this talk about "just use your VB6 code as is and interop with .Net"....
Suppose people buy into that. Now, what good is your "managed" B# code? As
soon as you hook up an external "unmanaged" library, the entire app becomes
"unmanaged".... or, is "partially secure" fine for most? Similar to your
bank placing a 3 foot thick steel door on one side of the vault and a rusty
screen door on the other. That entire vault is "unmanaged"

Bottom line: If you have an urge to write code using the latest MS
technology but you're constantly relying on VB5/6 to get you out of hot
water, what good is this new technology? It's more productive? I still
haven't seen proof of that. Every piece of .Net code I've seen that does
anything "real" takes reams of extra typing... over and beyond VB6
requirements.

 

[Ken Halter]

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.

 

[Saga]

Interesting point.

Perhaps Interoping is a quick way to get into .NET, but it seems
to me that it like walking in the middle of the road. I would prefer
to either do .NET or VB6, but not a mix of the two, unless the
points that you express are irrelevant for that case.

Saga

 

[YYZ]

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

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

And then, when you have to upgrade to .Net, most if not all of those
functions and subs do not work without massaging. You aren't familiar
with .Net, and you don't immediately know WHY they don't work, so you
have to do some digging.

You find several ways to read a file in .Net, however, you don't know
the intricacies and gotcha's of each method, like you do in VB6, so you
dont know which one to use. In VB6, you've already learned that you
should use "FreeFile" to figure out a file number, and not just assume
that #1 is going to be fine for what you need (even though you were
taught to use #1 from an example on MS's own site). You've already
learned to avoid all the headaches, and you've written reusable and
robust code that you can count on, and more importantly that you can
drop into any existing project and it "just works".

Now, take that file manipulation code, and add in database access, app
settings, random generic routines, error handling support routines,
shell and wait, flexgrid helper functions, farpoint grid helper class,
infragistics support functions, standard control helper functions,
animation control class from vbaccelerator, registry access class,
stopwatch class, custom usercontrols, cgi code to make cgi programs a
snap to write, and about 50 other useful things.

I've got about 5000 lines of code in all those things I mentioned --
not very much, honestly. And yet each and every line is very important
to me -- these are only the things that I drop in most projects,
depending on the need. I can count on them...I bet my livelihood on
them every single day.

They do not upgrade to .Net. The simplest procedures that I have do
not upgrade without warnings or outright compile errors. I am an
intelligent guy, but trying to upgrade all of this seems like a very
daunting challenge, and one that doesn't pay.

That's not even counting trying to upgrade my forms. You know, where
you upgrade and you get neat little messages like "Form Unload has been
renamed and has new behviour". Yeah, like THAT little change isn't
going to get anyone. And the dir function doesn't work like expected
anymore. Why? Why not have DirOld and DirNew? Fine, change MY Dir to
DirOld and take Dir for yourself, .Net...but let me keep my code that
works.

Why don't both work? No one has told me why. I don't think they can.

Matt

 

[Herfried K. Wagner [MVP]]

WOW... exactly the way the VB5 to VB6 conversion worked. What a concept!
<g> Except there were zero deprecated APIs

Yeah, that's how it actually should work if any new version is introduced.

 

[Stefan Berglund]

I toyed with .FRED here and there and honestly, I would prefer to write a
few lines of solid VB classic code then to have to remember
My.Computer.Drives.Folder.Files.This.That.TheOtherThing.etc. to acheive one
goal. Even with Intellisense it's still basically (no pun intended) a
completely different syntax for which would require endless poking and
proding in the Object Browser (if .NOT even has one) just to make sure I'm
"doing it right".

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. Unfortunately for myself, I'm one of
those people who doles out second chances on a very limited basis when my
trust has been deliberately stomped on and thrown away like an empty old
paint can. <g>

- Kev

That's it in a nutshell, Kev. And when the rest of the .NOT cheerleaders wake
up from their marketing Kool-Aid induced stupor, they (the smart ones at least)
will realize that what's good for MS may not really be what's best for them.

 

[Gary Nelson]

RR,

You can interOp between VB.net and VB6.

Sure Roger, again I repeat:

Have you any idea of the amount of work that it would take to create all of
the interop DLLs for a large program?

I use control arrays on nearly every form, exactly what good can interop do
for me in those cases?

I could go on, but these arguments have been repeated many times.

This argument from VB6ers about
having to convert everything before being able to take advantage of the
power of the dotNet platform is just plain idiotic. Maintain existing code
in VB6. Look for opportunities to leverage .Net for new functionality.
Instead many VB6ers respond that if they cant have it all .NET then they
wont have any of it at all. All the while complaining that Microsoft is
abandoning them.

Look Roger, May I suggest that you don't go on about things that you
obviously don't understand. I have been selling the same program since 1992
(VB2), and before that I sold the same program in PDS. The only path I have
is to make a full conversion of the program to .NET or continue as long as I
can in VB6.

On the one hand you guys say "we cant upgrade because we have too much
code". So some one says "hey here's how dotNet can reduce the amount of
code
you have to write, maintain and deploy", and you guys respond... "we cant
use that because we've got too much code?"

I get the feeling that you don't read the posts you are responding to. Who
is going to pay for the down time while we do the conversion. Any offers?

Gary

 

[mayayana]

i remember when I was in college using very old versions of c++, some

changes could be made by just directly accessing (writing to) the memory.
Than operating systems introduced proper apis, and now we couldnt do things
through direct memory access and there was an api for everything. Now there
is .net. I think its there system and they can dictate us how to use it.

That's an interesting point of view. Why so
passive? I have a Toyota pickup truck. If Toyota
announced that they would no longer sell parts
because their pickup truck model is "outdated"
and was being "End of lifed" then I wouldn't say,
"Well, it's Toyota's system. It's their decision."
That would be my last Toyota.

but people all over the world are installing service packs for windows 2000
and windows xp for security reasons which already contain the runtimes.

That sounds like a quote from some kind of wacky
..Net recruiting propaganda. As I recall, the last XP SP
was about 275 MB. A dial-up user can't download
something like that. Do you really think that people
send away for the service pack CDs? I don't know
anyone (among non-tech friends) who has ever
installed any service pack. I don't even know anyone
who has ever deliberately "upgraded" their Windows
version.

I have seen the Mono project and the applications that are being made on it.
They never compaint on how slow the windows forms are or what features it
lacks so that it becomes absolutely rediculous to make any serious
appliction in windows forms. They are doing everything. Novell now uses
there own made .net (mono). I'm not talking about speed but the greate
obbject-oriented framework and executiong engine .net offers that make any
kind of application development (web or desk) extremely rad and easy. There
are project on sourceforge of desk apps made in windows forms and also made
in short time.

Did you read the article? Mark Russinovich is a
Windows programming expert. He's not saying
that .Net lacks features. He's saying that it's sloppy
with resources, especially in terms of RAM
requirements; so much so that trying to run the typical
number programs at the same time, on current hardware,
if they were all written in .Net, would be undoable.

what u said about the OCX. When you move to .net, you get absolutely amazing
component based framework. Seriously there is no comparison with COM. Arnt
you happy that every one can learn to write there own components with out
learning how the heck IUnknown and IDispatch works. VB6 did make the
components writing easy but still the power of c++ on com could beat the
crap out of vb (i hope i used the english here correctly!!!!!!).

Yes, you seem to have a good grasp of English slang!
It is a crude usage, like one might hear in a bar between two
arguing drunks, but you used it correctly.

Now in .net
its not that about you write components inC# or vb.net, its just the same
for every language.

I think you might have misunderstood me there.
Again, I'm not questioning that .Net may have lots
of good components. And maybe .Net is good for
writing components. But I'm saying that I think
components are best avoided when possible in
desktop software because they create dependencies,
inefficiency and bloat. External components are
great to ease the "learning curve", but to a great extent
they are just training wheels pasted on top of the code
that actually does the work.

Part of that is also personal preference on my
part:
I enjoy the craft of perfecting code and I think that it
pays off in the long run. For instance, in VB, if
I want to send an email, at one extreme I could
automate Outlook. If I want to go deeper I can
use MAPI. Deeper still, I can use a winsock
OCX and code the whole operation. Or I can
use the system sockets library directly and skip the
OCX. Each step down requires more work to write
the code. But each step down is also more efficient,
with less dependencies and a smaller memory
footprint. I can load 40 MB(?) of libraries to use
Outlook, with 1 KB of code, or I can load the 40 KB
wsock32.dll and write 30 KB of code. There are tradeoffs
both ways, so it's nice to have the choice. Some
people would say that my 30 KB of code is sloppy,
but that's only because they don't see the millions
of operations that are running invisibly, and the
multiple megabytes worth of libraries being loaded,
when they run something like:
"System.Mail.SendAnEmail".

nothing like that, (i'm not even an mvp!). For me, .net is just amazing.

I didn't mean to accuse you of that. This thread
is posting in the VB6 group and the .Net group at
the same time. I made that comment because in the
VB6 group we continually get visiting .Net fanatics who
want to argue whenever anything critical is said about
..Net.