By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
445,732 Members | 1,429 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 445,732 IT Pros & Developers. It's quick & easy.

VB6 -vs -vb2005

P: n/a
I am presently a user of classic vb6 and hang out on those newsgroups. Some
of you may be aware that there is a very anti MS and vb2005 feeling there. I
have tried to get them to tell me which features of vb2005 are actually
worse then vb6 in practice, and forget the philosophy of backward
compatibility for a moment.

I would now like to hear "the other side". Could *anyone who previously used
vb6* (only those pleased; I feel the others will not be able to make the
comparison) tell me if the move to dotnet was a good idea. Leave aside the
needs of your workplace, future proofing etc. and say whether you regret the
move or not, and the reasons for your answer.

Apologies if this is the wrong group. If it is, perhaps you'll tell me which
dotnet group is the best one. Oh, and which is the best one for beginners or
'converts'. Thanks v much
Mar 22 '07 #1
Share this Question
Share on Google+
15 Replies


P: n/a
On Mar 22, 3:03 pm, "Aalaan" <veryinva...@invalid.comwrote:
I am presently a user of classic vb6 and hang out on those newsgroups. Some
of you may be aware that there is a very anti MS and vb2005 feeling there. I
have tried to get them to tell me which features of vb2005 are actually
worse then vb6 in practice, and forget the philosophy of backward
compatibility for a moment.

I would now like to hear "the other side". Could *anyone who previously used
vb6* (only those pleased; I feel the others will not be able to make the
comparison) tell me if the move to dotnet was a good idea. Leave aside the
needs of your workplace, future proofing etc. and say whether you regret the
move or not, and the reasons for your answer.

Apologies if this is the wrong group. If it is, perhaps you'll tell me which
dotnet group is the best one. Oh, and which is the best one for beginners or
'converts'. Thanks v much
Hi Aalaan,

I started using Visual Basic with version 1.0. I've used every version
since then. I watched it go from its most basic version, which was
*extremely* rudimentary but enabled you to write very basic Windows
applications with no MDI support, to version 6.0, where you could
write ActiveX components, COM DLLs, and full-fledged Windows
applications. I watched the whole history. I was there for it all.

I approached .NET with a lot of enthusiasm--and a lot of baggage.
There were things that I wanted to be able to do in VB6 that I *simply
could not do.* Or, if I wanted to do them, the amount of code that I
had to write was enormous, and I had to invoke obscure API functions
which, if I was not very careful, crashed my program (or, in the worst
case scenario, the user's machine.

At first, moving to .NET was difficult. I had to unlearn a lot of
things. But in the long run, it proved to be a worthwhile investment.
I haven't looked back since. These days, I'm loathe to work with VB6
code, and dread having to maintain our legacy VB6 code. I'd rather
port it .NET because the .NET code is more stable, easier to document,
and more secure.

There were a few things that VB6 had going for it:

- It was a great prototyping platform. You could whip things up in a
jiffy. The problem was, too many prototypes became production
software. I'm not whipping that out of my butt. I watched it happen,
time and again. "We'll just do the UI prototype in VB." Next thing you
know, the "prototype" is the application. (To this day, I refuse to
use development software to prepare UI prototypes. I do them in
Visio.)

- It was a great tool for experimentation. If you wanted to figure out
how to do something, or whether or not something was feasible, without
having to build a full framework, you could do it in VB6 in a few
minutes, and determine its feasibility. Sometimes, that's a lot harder
to do in .NET (though that's not always the case). And there's still
that problem that classic VB applications tend to become production
applications.

- When you NEEDED to ignore the data type of a variable, you could.
All the religous arguments aside, the Variant served a discrete
purpose when it came into being. It was an intrinsic part of COM, and
COM was created to solve a certain set of problems. And for a while,
COM solved those problems very well. Unfortunately, COM's
effectiveness was short-lived; DLL Hell ruined it. COM's problems,
however, are one of the key issues that led to many of the design
decisions in .NET.

- There was a plethora of available 3rd party components for it. That
doesn't mean they were all worth what you paid for, but the chances
were very high that you could find what you were looking for. And if
you couldn't find one, and you had the time, you could roll your own
control with a little time and careful coding.

Others will have their opinions about things that made classic VB a
great platform. Things like the fact that it was so easy to learn, it
was pervasive, it was affordable, you could find books about it just
about anywhere, the language was built into the Office suite, and so
on. But even with all of that, there were some fairly serious
drawbacks to it:

- Classic Visual Basic was never a truly type-safe language. Type-
safety is a critical part of writing secure code. It ensures that my
code doesn't write over someone else's memory. .NET is fanatical about
type safety.

- As useful as the Variant was, it was sometimes difficult to debug,
because it tended to be overused. Its abuse wasn't always intentional.
A lot of developers were self-taught; they didn't understand the
importance of Option Strict, which was a relatively late addition to
the language. Consequently, the default data type for many variables
was a Variant. This meant that many variables became Variants by
default and their data types were subject to spontaneous changes as
the software ran. These types of defects are notoriously difficult to
debug.

- Classic VB was never truly object oriented. It supported the
*notion* of objects--and COM's notion of objects, at that--but it
didn't support implementation inheritance, polymorphism, overloading,
or overriding. You had to do all of that yourself through delegation.
This created massive code libraries where reams of code simply
forwarded function calls to other functions. And VB's objects didn't
support constructors.

- The error handling system in VB was always (in my personal opinion)
kludgy at best. You could either use On Error Resume Next or On Error
GoTo. And trying to nest error handlers quickly got messy. Anyone who
didn't know how to properly handle errors was in for a whole world of
hurt.

So, along comes VB.NET. I have yet to run into anything that I could
do in classic VB that I can't to in VB.NET. Further, my code is more
secure is because it's type-safe; I don't have to hand-code calls to
the Win32 API anymore; structured exception handling is far superior
to the error handling in classic VB; I get full support for all of the
OOP principles, including objects with overloadable constructors; and
I still have a burgeoning supply of available 3rd party components at
my disposal.

In it's day, VB6 was a great platform, and I loved it. I swore by it.
I could write just about anything I needed to do in it. But bigger and
better things have come along. I haven't regretted the move to .NET.

I hope I have answered your question.

Mar 22 '07 #2

P: n/a
I'm sure this will become an extremely long thread (as this question always
provokes high debate). Here are my thoughts:

I've used every version of Visual Basic (starting with just BASIC), up to
and including VB.NET 2005 and the history of VB really has a line drawn
between VB 6.0 and everything that came after.

Frankly, I wish MS changed VB.NET's name to something different when .NET
came out because, while on the surface VB.NET and VB 6.0 look similar, they
are radically different in almost every way that counts.

In other words, the VB.NET of today and the VB 6.0 of days past are so
different (IMHO) that to try to say which is better is a joke because you
are comparing apples and gorillas.

There is no quesiton that VB.NET is better than VB 6.0. Here are just a few
reasons:

Memory Management (.NET Framework)
Separation of application managment from code.
Object-Oriented
More "mature" language features like short-circuiting and short-hand
operators.
Stuctured Exception Handling
The IDE

I really can't think of one thing that is/was better about VB 6.0.

"Aalaan" <ve*********@invalid.comwrote in message
news:46********@dnews.tpgi.com.au...
>I am presently a user of classic vb6 and hang out on those newsgroups. Some
of you may be aware that there is a very anti MS and vb2005 feeling there.
I have tried to get them to tell me which features of vb2005 are actually
worse then vb6 in practice, and forget the philosophy of backward
compatibility for a moment.

I would now like to hear "the other side". Could *anyone who previously
used vb6* (only those pleased; I feel the others will not be able to make
the comparison) tell me if the move to dotnet was a good idea. Leave aside
the needs of your workplace, future proofing etc. and say whether you
regret the move or not, and the reasons for your answer.

Apologies if this is the wrong group. If it is, perhaps you'll tell me
which dotnet group is the best one. Oh, and which is the best one for
beginners or 'converts'. Thanks v much

Mar 22 '07 #3

P: n/a
My goodness Mike! I could hardly ask for a fuller answer. Actually, the
message to me is probably not what you intended! I do want to run up things
reasonably quickly and have a language that is *relatively* easy and
intuitive to learn (though after 650 hours at it I wouldn't call it exactly
easy). I don't think I'll be writing any big corporate apps. An accounting
system for small business is about my peak and I'm well into that with vb6
now, having got the cashbook and GST parts polished and in live use. But,
you know, the feeling in the classic vb groups against dotnet and Microsoft
is so strong that I felt I had to hear "the other side". Your very full
answer has helped me enormously. Thanks.

"Mike Hofer" <kc********@gmail.comwrote in message
news:11**********************@n59g2000hsh.googlegr oups.com...
On Mar 22, 3:03 pm, "Aalaan" <veryinva...@invalid.comwrote:
>I am presently a user of classic vb6 and hang out on those newsgroups.
Some
of you may be aware that there is a very anti MS and vb2005 feeling
there. I
have tried to get them to tell me which features of vb2005 are actually
worse then vb6 in practice, and forget the philosophy of backward
compatibility for a moment.

I would now like to hear "the other side". Could *anyone who previously
used
vb6* (only those pleased; I feel the others will not be able to make the
comparison) tell me if the move to dotnet was a good idea. Leave aside
the
needs of your workplace, future proofing etc. and say whether you regret
the
move or not, and the reasons for your answer.

Apologies if this is the wrong group. If it is, perhaps you'll tell me
which
dotnet group is the best one. Oh, and which is the best one for beginners
or
'converts'. Thanks v much

Hi Aalaan,

I started using Visual Basic with version 1.0. I've used every version
since then. I watched it go from its most basic version, which was
*extremely* rudimentary but enabled you to write very basic Windows
applications with no MDI support, to version 6.0, where you could
write ActiveX components, COM DLLs, and full-fledged Windows
applications. I watched the whole history. I was there for it all.

I approached .NET with a lot of enthusiasm--and a lot of baggage.
There were things that I wanted to be able to do in VB6 that I *simply
could not do.* Or, if I wanted to do them, the amount of code that I
had to write was enormous, and I had to invoke obscure API functions
which, if I was not very careful, crashed my program (or, in the worst
case scenario, the user's machine.

At first, moving to .NET was difficult. I had to unlearn a lot of
things. But in the long run, it proved to be a worthwhile investment.
I haven't looked back since. These days, I'm loathe to work with VB6
code, and dread having to maintain our legacy VB6 code. I'd rather
port it .NET because the .NET code is more stable, easier to document,
and more secure.

There were a few things that VB6 had going for it:

- It was a great prototyping platform. You could whip things up in a
jiffy. The problem was, too many prototypes became production
software. I'm not whipping that out of my butt. I watched it happen,
time and again. "We'll just do the UI prototype in VB." Next thing you
know, the "prototype" is the application. (To this day, I refuse to
use development software to prepare UI prototypes. I do them in
Visio.)

- It was a great tool for experimentation. If you wanted to figure out
how to do something, or whether or not something was feasible, without
having to build a full framework, you could do it in VB6 in a few
minutes, and determine its feasibility. Sometimes, that's a lot harder
to do in .NET (though that's not always the case). And there's still
that problem that classic VB applications tend to become production
applications.

- When you NEEDED to ignore the data type of a variable, you could.
All the religous arguments aside, the Variant served a discrete
purpose when it came into being. It was an intrinsic part of COM, and
COM was created to solve a certain set of problems. And for a while,
COM solved those problems very well. Unfortunately, COM's
effectiveness was short-lived; DLL Hell ruined it. COM's problems,
however, are one of the key issues that led to many of the design
decisions in .NET.

- There was a plethora of available 3rd party components for it. That
doesn't mean they were all worth what you paid for, but the chances
were very high that you could find what you were looking for. And if
you couldn't find one, and you had the time, you could roll your own
control with a little time and careful coding.

Others will have their opinions about things that made classic VB a
great platform. Things like the fact that it was so easy to learn, it
was pervasive, it was affordable, you could find books about it just
about anywhere, the language was built into the Office suite, and so
on. But even with all of that, there were some fairly serious
drawbacks to it:

- Classic Visual Basic was never a truly type-safe language. Type-
safety is a critical part of writing secure code. It ensures that my
code doesn't write over someone else's memory. .NET is fanatical about
type safety.

- As useful as the Variant was, it was sometimes difficult to debug,
because it tended to be overused. Its abuse wasn't always intentional.
A lot of developers were self-taught; they didn't understand the
importance of Option Strict, which was a relatively late addition to
the language. Consequently, the default data type for many variables
was a Variant. This meant that many variables became Variants by
default and their data types were subject to spontaneous changes as
the software ran. These types of defects are notoriously difficult to
debug.

- Classic VB was never truly object oriented. It supported the
*notion* of objects--and COM's notion of objects, at that--but it
didn't support implementation inheritance, polymorphism, overloading,
or overriding. You had to do all of that yourself through delegation.
This created massive code libraries where reams of code simply
forwarded function calls to other functions. And VB's objects didn't
support constructors.

- The error handling system in VB was always (in my personal opinion)
kludgy at best. You could either use On Error Resume Next or On Error
GoTo. And trying to nest error handlers quickly got messy. Anyone who
didn't know how to properly handle errors was in for a whole world of
hurt.

So, along comes VB.NET. I have yet to run into anything that I could
do in classic VB that I can't to in VB.NET. Further, my code is more
secure is because it's type-safe; I don't have to hand-code calls to
the Win32 API anymore; structured exception handling is far superior
to the error handling in classic VB; I get full support for all of the
OOP principles, including objects with overloadable constructors; and
I still have a burgeoning supply of available 3rd party components at
my disposal.

In it's day, VB6 was a great platform, and I loved it. I swore by it.
I could write just about anything I needed to do in it. But bigger and
better things have come along. I haven't regretted the move to .NET.

I hope I have answered your question.

Mar 22 '07 #4

P: n/a
Thanks Scott.

How about this? I'm told that

a) dotnet source code can be easily read/dissembled

b) I can't easily produce *.exe files using dotnet.

c) There have *already* been backward compatibility problems *since* the
advent of dotnet and the launch of newer versions.

"Scott M." <s-***@nospam.nospamwrote in message
news:%2****************@TK2MSFTNGP04.phx.gbl...
I'm sure this will become an extremely long thread (as this question
always provokes high debate). Here are my thoughts:

I've used every version of Visual Basic (starting with just BASIC), up to
and including VB.NET 2005 and the history of VB really has a line drawn
between VB 6.0 and everything that came after.

Frankly, I wish MS changed VB.NET's name to something different when .NET
came out because, while on the surface VB.NET and VB 6.0 look similar,
they are radically different in almost every way that counts.

In other words, the VB.NET of today and the VB 6.0 of days past are so
different (IMHO) that to try to say which is better is a joke because you
are comparing apples and gorillas.

There is no quesiton that VB.NET is better than VB 6.0. Here are just a
few reasons:

Memory Management (.NET Framework)
Separation of application managment from code.
Object-Oriented
More "mature" language features like short-circuiting and short-hand
operators.
Stuctured Exception Handling
The IDE

I really can't think of one thing that is/was better about VB 6.0.

"Aalaan" <ve*********@invalid.comwrote in message
news:46********@dnews.tpgi.com.au...
>>I am presently a user of classic vb6 and hang out on those newsgroups.
Some of you may be aware that there is a very anti MS and vb2005 feeling
there. I have tried to get them to tell me which features of vb2005 are
actually worse then vb6 in practice, and forget the philosophy of backward
compatibility for a moment.

I would now like to hear "the other side". Could *anyone who previously
used vb6* (only those pleased; I feel the others will not be able to make
the comparison) tell me if the move to dotnet was a good idea. Leave
aside the needs of your workplace, future proofing etc. and say whether
you regret the move or not, and the reasons for your answer.

Apologies if this is the wrong group. If it is, perhaps you'll tell me
which dotnet group is the best one. Oh, and which is the best one for
beginners or 'converts'. Thanks v much


Mar 22 '07 #5

P: n/a
VJ
Yes Aalaan

You would see that problem between VB and .NET in terms of code reverse
engineer. But there are ways to protect that. Obfuscator like tools make it
tough, and Linker tools make it almost impossible to do so. The good thing
would be is to move to .NET, not sure how much support will be there for VB
6.0 Apps in 64 Bit world that is not too far out in the future..!! This
specifically if you are trying to build of the shelf products.

VJ

"Scott M." <s-***@nospam.nospamwrote in message
news:%2****************@TK2MSFTNGP04.phx.gbl...
I'm sure this will become an extremely long thread (as this question
always provokes high debate). Here are my thoughts:

I've used every version of Visual Basic (starting with just BASIC), up to
and including VB.NET 2005 and the history of VB really has a line drawn
between VB 6.0 and everything that came after.

Frankly, I wish MS changed VB.NET's name to something different when .NET
came out because, while on the surface VB.NET and VB 6.0 look similar,
they are radically different in almost every way that counts.

In other words, the VB.NET of today and the VB 6.0 of days past are so
different (IMHO) that to try to say which is better is a joke because you
are comparing apples and gorillas.

There is no quesiton that VB.NET is better than VB 6.0. Here are just a
few reasons:

Memory Management (.NET Framework)
Separation of application managment from code.
Object-Oriented
More "mature" language features like short-circuiting and short-hand
operators.
Stuctured Exception Handling
The IDE

I really can't think of one thing that is/was better about VB 6.0.

"Aalaan" <ve*********@invalid.comwrote in message
news:46********@dnews.tpgi.com.au...
>>I am presently a user of classic vb6 and hang out on those newsgroups.
Some of you may be aware that there is a very anti MS and vb2005 feeling
there. I have tried to get them to tell me which features of vb2005 are
actually worse then vb6 in practice, and forget the philosophy of backward
compatibility for a moment.

I would now like to hear "the other side". Could *anyone who previously
used vb6* (only those pleased; I feel the others will not be able to make
the comparison) tell me if the move to dotnet was a good idea. Leave
aside the needs of your workplace, future proofing etc. and say whether
you regret the move or not, and the reasons for your answer.

Apologies if this is the wrong group. If it is, perhaps you'll tell me
which dotnet group is the best one. Oh, and which is the best one for
beginners or 'converts'. Thanks v much


Mar 22 '07 #6

P: n/a
How about this? I'm told that
>
a) dotnet source code can be easily read/dissembled
Yes, that's true. Unless you obfuscate your code, which is entirely
possible.
b) I can't easily produce *.exe files using dotnet.
Where did you hear that? That is completely false.
c) There have *already* been backward compatibility problems *since* the
advent of dotnet and the launch of newer versions.
Again, where are you getting this bogus information? When you compile a
..NET assembly, you target it to a specific version of the framework, so a
1.0 assembly needs the 1.0 framework. It's not like the 1.1 Framework
attempts to run a 1.0 assembly. This is done to ensure there won't be
compatiblity problems.
>
"Scott M." <s-***@nospam.nospamwrote in message
news:%2****************@TK2MSFTNGP04.phx.gbl...
>I'm sure this will become an extremely long thread (as this question
always provokes high debate). Here are my thoughts:

I've used every version of Visual Basic (starting with just BASIC), up to
and including VB.NET 2005 and the history of VB really has a line drawn
between VB 6.0 and everything that came after.

Frankly, I wish MS changed VB.NET's name to something different when .NET
came out because, while on the surface VB.NET and VB 6.0 look similar,
they are radically different in almost every way that counts.

In other words, the VB.NET of today and the VB 6.0 of days past are so
different (IMHO) that to try to say which is better is a joke because you
are comparing apples and gorillas.

There is no quesiton that VB.NET is better than VB 6.0. Here are just a
few reasons:

Memory Management (.NET Framework)
Separation of application managment from code.
Object-Oriented
More "mature" language features like short-circuiting and short-hand
operators.
Stuctured Exception Handling
The IDE

I really can't think of one thing that is/was better about VB 6.0.

"Aalaan" <ve*********@invalid.comwrote in message
news:46********@dnews.tpgi.com.au...
>>>I am presently a user of classic vb6 and hang out on those newsgroups.
Some of you may be aware that there is a very anti MS and vb2005 feeling
there. I have tried to get them to tell me which features of vb2005 are
actually worse then vb6 in practice, and forget the philosophy of
backward compatibility for a moment.

I would now like to hear "the other side". Could *anyone who previously
used vb6* (only those pleased; I feel the others will not be able to
make the comparison) tell me if the move to dotnet was a good idea.
Leave aside the needs of your workplace, future proofing etc. and say
whether you regret the move or not, and the reasons for your answer.

Apologies if this is the wrong group. If it is, perhaps you'll tell me
which dotnet group is the best one. Oh, and which is the best one for
beginners or 'converts'. Thanks v much



Mar 23 '07 #7

P: n/a
>>"Aalaan" <ve*********@invalid.comwrote in message
>>>I would now like to hear "the other side". Could *anyone who previously
used vb6* (only those pleased; I feel the others...
Oh dear, just noticed this typo! I meant "only those, please; I feel the
others..."

Of course I'd also like to hear from those who do not look back with
approval! Anyone who has actually got experience with both! Good and bad.
That's what I meant.
Mar 23 '07 #8

P: n/a

I agree with everything Mike says.

And I have to admit, being able to build the project and see *all* of the
errors and fix them before building again is great, and I love being able
to put in regions and being able to collapse and expand methods. And does
anybody else love code snippets, or is it just me? And data binding! It
actually works now! The thrill of it all!

It's those little conveniences that you really miss when you do .Net and
then you have to go back and maintain a VB6 application.

If you want some help moving up to .Net, I have some books to recommend.
The first is Deborah Kurata's "Doing Objects in VB2005". This explains the
3-tier architecture (UI layer, business layer, and data access layer), and
how to implement it. You end up building a small application. It's very
pragmatic, and throws in some things like how to store user settings, use
code snippets and even write your own, access SQLServer from Visual Studio,
etc. This book really helped me a lot. And I'm not just saying that because
my quote about it helping me move from VB6 to VB2005 is on the back of the
book. :-)

The other one I read cover to cover was Francesco Balena's "VB2005: The
Language". It has a lot of info about VB6 versus VB2005. It only covers the
language, not the forms or data access.

For data access, I turn to Dave Sceppa's "ADO.Net: The Core Reference". And
if you're doing SQLServer, check out Bill Vaughn's book, "Hitchhiker's
Guide to Visual Studio and SQLServer".

I am really enjoying my .Net experience, and have had a great time
rewriting my VB6 stuff in .Net. I hope you do, too.

Robin S.
Ts'i mahnu uterna ot twan ot geifur hingts uto.
-----------------------------------------------
"Mike Hofer" <kc********@gmail.comwrote in message
news:11**********************@n59g2000hsh.googlegr oups.com...
On Mar 22, 3:03 pm, "Aalaan" <veryinva...@invalid.comwrote:
>I am presently a user of classic vb6 and hang out on those newsgroups.
Some
of you may be aware that there is a very anti MS and vb2005 feeling
there. I
have tried to get them to tell me which features of vb2005 are actually
worse then vb6 in practice, and forget the philosophy of backward
compatibility for a moment.

I would now like to hear "the other side". Could *anyone who previously
used
vb6* (only those pleased; I feel the others will not be able to make the
comparison) tell me if the move to dotnet was a good idea. Leave aside
the
needs of your workplace, future proofing etc. and say whether you regret
the
move or not, and the reasons for your answer.

Apologies if this is the wrong group. If it is, perhaps you'll tell me
which
dotnet group is the best one. Oh, and which is the best one for
beginners or
'converts'. Thanks v much

Hi Aalaan,

I started using Visual Basic with version 1.0. I've used every version
since then. I watched it go from its most basic version, which was
*extremely* rudimentary but enabled you to write very basic Windows
applications with no MDI support, to version 6.0, where you could
write ActiveX components, COM DLLs, and full-fledged Windows
applications. I watched the whole history. I was there for it all.

I approached .NET with a lot of enthusiasm--and a lot of baggage.
There were things that I wanted to be able to do in VB6 that I *simply
could not do.* Or, if I wanted to do them, the amount of code that I
had to write was enormous, and I had to invoke obscure API functions
which, if I was not very careful, crashed my program (or, in the worst
case scenario, the user's machine.

At first, moving to .NET was difficult. I had to unlearn a lot of
things. But in the long run, it proved to be a worthwhile investment.
I haven't looked back since. These days, I'm loathe to work with VB6
code, and dread having to maintain our legacy VB6 code. I'd rather
port it .NET because the .NET code is more stable, easier to document,
and more secure.

There were a few things that VB6 had going for it:

- It was a great prototyping platform. You could whip things up in a
jiffy. The problem was, too many prototypes became production
software. I'm not whipping that out of my butt. I watched it happen,
time and again. "We'll just do the UI prototype in VB." Next thing you
know, the "prototype" is the application. (To this day, I refuse to
use development software to prepare UI prototypes. I do them in
Visio.)

- It was a great tool for experimentation. If you wanted to figure out
how to do something, or whether or not something was feasible, without
having to build a full framework, you could do it in VB6 in a few
minutes, and determine its feasibility. Sometimes, that's a lot harder
to do in .NET (though that's not always the case). And there's still
that problem that classic VB applications tend to become production
applications.

- When you NEEDED to ignore the data type of a variable, you could.
All the religous arguments aside, the Variant served a discrete
purpose when it came into being. It was an intrinsic part of COM, and
COM was created to solve a certain set of problems. And for a while,
COM solved those problems very well. Unfortunately, COM's
effectiveness was short-lived; DLL Hell ruined it. COM's problems,
however, are one of the key issues that led to many of the design
decisions in .NET.

- There was a plethora of available 3rd party components for it. That
doesn't mean they were all worth what you paid for, but the chances
were very high that you could find what you were looking for. And if
you couldn't find one, and you had the time, you could roll your own
control with a little time and careful coding.

Others will have their opinions about things that made classic VB a
great platform. Things like the fact that it was so easy to learn, it
was pervasive, it was affordable, you could find books about it just
about anywhere, the language was built into the Office suite, and so
on. But even with all of that, there were some fairly serious
drawbacks to it:

- Classic Visual Basic was never a truly type-safe language. Type-
safety is a critical part of writing secure code. It ensures that my
code doesn't write over someone else's memory. .NET is fanatical about
type safety.

- As useful as the Variant was, it was sometimes difficult to debug,
because it tended to be overused. Its abuse wasn't always intentional.
A lot of developers were self-taught; they didn't understand the
importance of Option Strict, which was a relatively late addition to
the language. Consequently, the default data type for many variables
was a Variant. This meant that many variables became Variants by
default and their data types were subject to spontaneous changes as
the software ran. These types of defects are notoriously difficult to
debug.

- Classic VB was never truly object oriented. It supported the
*notion* of objects--and COM's notion of objects, at that--but it
didn't support implementation inheritance, polymorphism, overloading,
or overriding. You had to do all of that yourself through delegation.
This created massive code libraries where reams of code simply
forwarded function calls to other functions. And VB's objects didn't
support constructors.

- The error handling system in VB was always (in my personal opinion)
kludgy at best. You could either use On Error Resume Next or On Error
GoTo. And trying to nest error handlers quickly got messy. Anyone who
didn't know how to properly handle errors was in for a whole world of
hurt.

So, along comes VB.NET. I have yet to run into anything that I could
do in classic VB that I can't to in VB.NET. Further, my code is more
secure is because it's type-safe; I don't have to hand-code calls to
the Win32 API anymore; structured exception handling is far superior
to the error handling in classic VB; I get full support for all of the
OOP principles, including objects with overloadable constructors; and
I still have a burgeoning supply of available 3rd party components at
my disposal.

In it's day, VB6 was a great platform, and I loved it. I swore by it.
I could write just about anything I needed to do in it. But bigger and
better things have come along. I haven't regretted the move to .NET.

I hope I have answered your question.

Mar 23 '07 #9

P: n/a

"Aalaan" <ve*********@invalid.comwrote in message
news:46******@dnews.tpgi.com.au...
My goodness Mike! I could hardly ask for a fuller answer. Actually, the
message to me is probably not what you intended! I do want to run up
things reasonably quickly and have a language that is *relatively* easy
and intuitive to learn (though after 650 hours at it I wouldn't call it
exactly easy).
It's a completely different paradigm from VB6. You can write VB6-like code
in VB2005, but it's not the point.

In 5 months, I read about a dozen books, over 7,000 pages (really, I'm not
kidding), and wrote thousands of lines of code to "get it". (I'm an
overachiever, in case you didn't figure that out. ;-)

Of the books I recommended in my other post, the one that helped me
understand OOP the best was Deborah Kurata's.

Good luck.
Robin S.
Ts'i mahnu uterna ot twan ot geifur hingts uto.
Mar 23 '07 #10

P: n/a
Hi Scott
I'm sure this will become an extremely long thread (as this question
always provokes high debate). Here are my thoughts:
I thought that as well, because in this newsgroup .....(you know what I
mean) and would tell to turn over to the vb.net newsgroup.

However agains the great description of Mike is not any trolling possible in
my eyes.

Cor
Mar 23 '07 #11

P: n/a
Mike,

Compliments, very well written.

Cor

"Mike Hofer" <kc********@gmail.comschreef in bericht
news:11**********************@n59g2000hsh.googlegr oups.com...
On Mar 22, 3:03 pm, "Aalaan" <veryinva...@invalid.comwrote:
>I am presently a user of classic vb6 and hang out on those newsgroups.
Some
of you may be aware that there is a very anti MS and vb2005 feeling
there. I
have tried to get them to tell me which features of vb2005 are actually
worse then vb6 in practice, and forget the philosophy of backward
compatibility for a moment.

I would now like to hear "the other side". Could *anyone who previously
used
vb6* (only those pleased; I feel the others will not be able to make the
comparison) tell me if the move to dotnet was a good idea. Leave aside
the
needs of your workplace, future proofing etc. and say whether you regret
the
move or not, and the reasons for your answer.

Apologies if this is the wrong group. If it is, perhaps you'll tell me
which
dotnet group is the best one. Oh, and which is the best one for beginners
or
'converts'. Thanks v much

Hi Aalaan,

I started using Visual Basic with version 1.0. I've used every version
since then. I watched it go from its most basic version, which was
*extremely* rudimentary but enabled you to write very basic Windows
applications with no MDI support, to version 6.0, where you could
write ActiveX components, COM DLLs, and full-fledged Windows
applications. I watched the whole history. I was there for it all.

I approached .NET with a lot of enthusiasm--and a lot of baggage.
There were things that I wanted to be able to do in VB6 that I *simply
could not do.* Or, if I wanted to do them, the amount of code that I
had to write was enormous, and I had to invoke obscure API functions
which, if I was not very careful, crashed my program (or, in the worst
case scenario, the user's machine.

At first, moving to .NET was difficult. I had to unlearn a lot of
things. But in the long run, it proved to be a worthwhile investment.
I haven't looked back since. These days, I'm loathe to work with VB6
code, and dread having to maintain our legacy VB6 code. I'd rather
port it .NET because the .NET code is more stable, easier to document,
and more secure.

There were a few things that VB6 had going for it:

- It was a great prototyping platform. You could whip things up in a
jiffy. The problem was, too many prototypes became production
software. I'm not whipping that out of my butt. I watched it happen,
time and again. "We'll just do the UI prototype in VB." Next thing you
know, the "prototype" is the application. (To this day, I refuse to
use development software to prepare UI prototypes. I do them in
Visio.)

- It was a great tool for experimentation. If you wanted to figure out
how to do something, or whether or not something was feasible, without
having to build a full framework, you could do it in VB6 in a few
minutes, and determine its feasibility. Sometimes, that's a lot harder
to do in .NET (though that's not always the case). And there's still
that problem that classic VB applications tend to become production
applications.

- When you NEEDED to ignore the data type of a variable, you could.
All the religous arguments aside, the Variant served a discrete
purpose when it came into being. It was an intrinsic part of COM, and
COM was created to solve a certain set of problems. And for a while,
COM solved those problems very well. Unfortunately, COM's
effectiveness was short-lived; DLL Hell ruined it. COM's problems,
however, are one of the key issues that led to many of the design
decisions in .NET.

- There was a plethora of available 3rd party components for it. That
doesn't mean they were all worth what you paid for, but the chances
were very high that you could find what you were looking for. And if
you couldn't find one, and you had the time, you could roll your own
control with a little time and careful coding.

Others will have their opinions about things that made classic VB a
great platform. Things like the fact that it was so easy to learn, it
was pervasive, it was affordable, you could find books about it just
about anywhere, the language was built into the Office suite, and so
on. But even with all of that, there were some fairly serious
drawbacks to it:

- Classic Visual Basic was never a truly type-safe language. Type-
safety is a critical part of writing secure code. It ensures that my
code doesn't write over someone else's memory. .NET is fanatical about
type safety.

- As useful as the Variant was, it was sometimes difficult to debug,
because it tended to be overused. Its abuse wasn't always intentional.
A lot of developers were self-taught; they didn't understand the
importance of Option Strict, which was a relatively late addition to
the language. Consequently, the default data type for many variables
was a Variant. This meant that many variables became Variants by
default and their data types were subject to spontaneous changes as
the software ran. These types of defects are notoriously difficult to
debug.

- Classic VB was never truly object oriented. It supported the
*notion* of objects--and COM's notion of objects, at that--but it
didn't support implementation inheritance, polymorphism, overloading,
or overriding. You had to do all of that yourself through delegation.
This created massive code libraries where reams of code simply
forwarded function calls to other functions. And VB's objects didn't
support constructors.

- The error handling system in VB was always (in my personal opinion)
kludgy at best. You could either use On Error Resume Next or On Error
GoTo. And trying to nest error handlers quickly got messy. Anyone who
didn't know how to properly handle errors was in for a whole world of
hurt.

So, along comes VB.NET. I have yet to run into anything that I could
do in classic VB that I can't to in VB.NET. Further, my code is more
secure is because it's type-safe; I don't have to hand-code calls to
the Win32 API anymore; structured exception handling is far superior
to the error handling in classic VB; I get full support for all of the
OOP principles, including objects with overloadable constructors; and
I still have a burgeoning supply of available 3rd party components at
my disposal.

In it's day, VB6 was a great platform, and I loved it. I swore by it.
I could write just about anything I needed to do in it. But bigger and
better things have come along. I haven't regretted the move to .NET.

I hope I have answered your question.

Mar 23 '07 #12

P: n/a
I believe most who post replies to your question have, most likely, enough
experience on both (VB5/6 and .NET. Here, I would choose .NET, rather than
VB.NET). You need read into between lines: if they do not know both well,
how could they answer you.

"Aalaan" <ve*********@invalid.comwrote in message
news:46********@dnews.tpgi.com.au...
>>>"Aalaan" <ve*********@invalid.comwrote in message
I would now like to hear "the other side". Could *anyone who
previously used vb6* (only those pleased; I feel the others...

Oh dear, just noticed this typo! I meant "only those, please; I feel the
others..."

Of course I'd also like to hear from those who do not look back with
approval! Anyone who has actually got experience with both! Good and bad.
That's what I meant.


Mar 23 '07 #13

P: n/a
Not sure I'm going to make the move yet. It be all a bit beyond me and a
complete overkill for the applications I wish to write. But in passing I
notice you mention Francesco. I have just obtained Francesco's book about
vb6. Very useful.

"RobinS" <Ro****@NoSpam.yah.nonewrote in message
news:a7******************************@comcast.com. ..
>
I agree with everything Mike says.

And I have to admit, being able to build the project and see *all* of the
errors and fix them before building again is great, and I love being able
to put in regions and being able to collapse and expand methods. And does
anybody else love code snippets, or is it just me? And data binding! It
actually works now! The thrill of it all!

It's those little conveniences that you really miss when you do .Net and
then you have to go back and maintain a VB6 application.

If you want some help moving up to .Net, I have some books to recommend.
The first is Deborah Kurata's "Doing Objects in VB2005". This explains the
3-tier architecture (UI layer, business layer, and data access layer), and
how to implement it. You end up building a small application. It's very
pragmatic, and throws in some things like how to store user settings, use
code snippets and even write your own, access SQLServer from Visual
Studio, etc. This book really helped me a lot. And I'm not just saying
that because my quote about it helping me move from VB6 to VB2005 is on
the back of the book. :-)

The other one I read cover to cover was Francesco Balena's "VB2005: The
Language". It has a lot of info about VB6 versus VB2005. It only covers
the language, not the forms or data access.

For data access, I turn to Dave Sceppa's "ADO.Net: The Core Reference".
And if you're doing SQLServer, check out Bill Vaughn's book, "Hitchhiker's
Guide to Visual Studio and SQLServer".

I am really enjoying my .Net experience, and have had a great time
rewriting my VB6 stuff in .Net. I hope you do, too.

Robin S.
Ts'i mahnu uterna ot twan ot geifur hingts uto.
-----------------------------------------------
"Mike Hofer" <kc********@gmail.comwrote in message
news:11**********************@n59g2000hsh.googlegr oups.com...
>On Mar 22, 3:03 pm, "Aalaan" <veryinva...@invalid.comwrote:
>>I am presently a user of classic vb6 and hang out on those newsgroups.
Some
of you may be aware that there is a very anti MS and vb2005 feeling
there. I
have tried to get them to tell me which features of vb2005 are actually
worse then vb6 in practice, and forget the philosophy of backward
compatibility for a moment.

I would now like to hear "the other side". Could *anyone who previously
used
vb6* (only those pleased; I feel the others will not be able to make the
comparison) tell me if the move to dotnet was a good idea. Leave aside
the
needs of your workplace, future proofing etc. and say whether you regret
the
move or not, and the reasons for your answer.

Apologies if this is the wrong group. If it is, perhaps you'll tell me
which
dotnet group is the best one. Oh, and which is the best one for
beginners or
'converts'. Thanks v much

Hi Aalaan,

I started using Visual Basic with version 1.0. I've used every version
since then. I watched it go from its most basic version, which was
*extremely* rudimentary but enabled you to write very basic Windows
applications with no MDI support, to version 6.0, where you could
write ActiveX components, COM DLLs, and full-fledged Windows
applications. I watched the whole history. I was there for it all.

I approached .NET with a lot of enthusiasm--and a lot of baggage.
There were things that I wanted to be able to do in VB6 that I *simply
could not do.* Or, if I wanted to do them, the amount of code that I
had to write was enormous, and I had to invoke obscure API functions
which, if I was not very careful, crashed my program (or, in the worst
case scenario, the user's machine.

At first, moving to .NET was difficult. I had to unlearn a lot of
things. But in the long run, it proved to be a worthwhile investment.
I haven't looked back since. These days, I'm loathe to work with VB6
code, and dread having to maintain our legacy VB6 code. I'd rather
port it .NET because the .NET code is more stable, easier to document,
and more secure.

There were a few things that VB6 had going for it:

- It was a great prototyping platform. You could whip things up in a
jiffy. The problem was, too many prototypes became production
software. I'm not whipping that out of my butt. I watched it happen,
time and again. "We'll just do the UI prototype in VB." Next thing you
know, the "prototype" is the application. (To this day, I refuse to
use development software to prepare UI prototypes. I do them in
Visio.)

- It was a great tool for experimentation. If you wanted to figure out
how to do something, or whether or not something was feasible, without
having to build a full framework, you could do it in VB6 in a few
minutes, and determine its feasibility. Sometimes, that's a lot harder
to do in .NET (though that's not always the case). And there's still
that problem that classic VB applications tend to become production
applications.

- When you NEEDED to ignore the data type of a variable, you could.
All the religous arguments aside, the Variant served a discrete
purpose when it came into being. It was an intrinsic part of COM, and
COM was created to solve a certain set of problems. And for a while,
COM solved those problems very well. Unfortunately, COM's
effectiveness was short-lived; DLL Hell ruined it. COM's problems,
however, are one of the key issues that led to many of the design
decisions in .NET.

- There was a plethora of available 3rd party components for it. That
doesn't mean they were all worth what you paid for, but the chances
were very high that you could find what you were looking for. And if
you couldn't find one, and you had the time, you could roll your own
control with a little time and careful coding.

Others will have their opinions about things that made classic VB a
great platform. Things like the fact that it was so easy to learn, it
was pervasive, it was affordable, you could find books about it just
about anywhere, the language was built into the Office suite, and so
on. But even with all of that, there were some fairly serious
drawbacks to it:

- Classic Visual Basic was never a truly type-safe language. Type-
safety is a critical part of writing secure code. It ensures that my
code doesn't write over someone else's memory. .NET is fanatical about
type safety.

- As useful as the Variant was, it was sometimes difficult to debug,
because it tended to be overused. Its abuse wasn't always intentional.
A lot of developers were self-taught; they didn't understand the
importance of Option Strict, which was a relatively late addition to
the language. Consequently, the default data type for many variables
was a Variant. This meant that many variables became Variants by
default and their data types were subject to spontaneous changes as
the software ran. These types of defects are notoriously difficult to
debug.

- Classic VB was never truly object oriented. It supported the
*notion* of objects--and COM's notion of objects, at that--but it
didn't support implementation inheritance, polymorphism, overloading,
or overriding. You had to do all of that yourself through delegation.
This created massive code libraries where reams of code simply
forwarded function calls to other functions. And VB's objects didn't
support constructors.

- The error handling system in VB was always (in my personal opinion)
kludgy at best. You could either use On Error Resume Next or On Error
GoTo. And trying to nest error handlers quickly got messy. Anyone who
didn't know how to properly handle errors was in for a whole world of
hurt.

So, along comes VB.NET. I have yet to run into anything that I could
do in classic VB that I can't to in VB.NET. Further, my code is more
secure is because it's type-safe; I don't have to hand-code calls to
the Win32 API anymore; structured exception handling is far superior
to the error handling in classic VB; I get full support for all of the
OOP principles, including objects with overloadable constructors; and
I still have a burgeoning supply of available 3rd party components at
my disposal.

In it's day, VB6 was a great platform, and I loved it. I swore by it.
I could write just about anything I needed to do in it. But bigger and
better things have come along. I haven't regretted the move to .NET.

I hope I have answered your question.


Mar 23 '07 #14

P: n/a
Aalaan,

Download VB 2005 Express and give it a spin. It's free and is a full
fledged VB 2005 compiler. I switched from VB 6 to VB 2005 and after about a
year of working in VB 2005, I am considering porting/rewriting all my VB 6
code into VB 2005. VB 2005 is that much better. However, watch out - the
automated transistion tools are lousy, so you are better off simply
rewriting.

Mike Ober.

"Aalaan" <ve*********@invalid.comwrote in message
news:46******@dnews.tpgi.com.au...
Not sure I'm going to make the move yet. It be all a bit beyond me and a
complete overkill for the applications I wish to write. But in passing I
notice you mention Francesco. I have just obtained Francesco's book about
vb6. Very useful.

"RobinS" <Ro****@NoSpam.yah.nonewrote in message
news:a7******************************@comcast.com. ..
>>
I agree with everything Mike says.

And I have to admit, being able to build the project and see *all* of the
errors and fix them before building again is great, and I love being able
to put in regions and being able to collapse and expand methods. And does
anybody else love code snippets, or is it just me? And data binding! It
actually works now! The thrill of it all!

It's those little conveniences that you really miss when you do .Net and
then you have to go back and maintain a VB6 application.

If you want some help moving up to .Net, I have some books to recommend.
The first is Deborah Kurata's "Doing Objects in VB2005". This explains
the 3-tier architecture (UI layer, business layer, and data access
layer), and how to implement it. You end up building a small application.
It's very pragmatic, and throws in some things like how to store user
settings, use code snippets and even write your own, access SQLServer
from Visual Studio, etc. This book really helped me a lot. And I'm not
just saying that because my quote about it helping me move from VB6 to
VB2005 is on the back of the book. :-)

The other one I read cover to cover was Francesco Balena's "VB2005: The
Language". It has a lot of info about VB6 versus VB2005. It only covers
the language, not the forms or data access.

For data access, I turn to Dave Sceppa's "ADO.Net: The Core Reference".
And if you're doing SQLServer, check out Bill Vaughn's book,
"Hitchhiker's Guide to Visual Studio and SQLServer".

I am really enjoying my .Net experience, and have had a great time
rewriting my VB6 stuff in .Net. I hope you do, too.

Robin S.
Ts'i mahnu uterna ot twan ot geifur hingts uto.
-----------------------------------------------
"Mike Hofer" <kc********@gmail.comwrote in message
news:11**********************@n59g2000hsh.googleg roups.com...
>>On Mar 22, 3:03 pm, "Aalaan" <veryinva...@invalid.comwrote:
I am presently a user of classic vb6 and hang out on those newsgroups.
Some
of you may be aware that there is a very anti MS and vb2005 feeling
there. I
have tried to get them to tell me which features of vb2005 are actually
worse then vb6 in practice, and forget the philosophy of backward
compatibility for a moment.

I would now like to hear "the other side". Could *anyone who previously
used
vb6* (only those pleased; I feel the others will not be able to make
the
comparison) tell me if the move to dotnet was a good idea. Leave aside
the
needs of your workplace, future proofing etc. and say whether you
regret the
move or not, and the reasons for your answer.

Apologies if this is the wrong group. If it is, perhaps you'll tell me
which
dotnet group is the best one. Oh, and which is the best one for
beginners or
'converts'. Thanks v much

Hi Aalaan,

I started using Visual Basic with version 1.0. I've used every version
since then. I watched it go from its most basic version, which was
*extremely* rudimentary but enabled you to write very basic Windows
applications with no MDI support, to version 6.0, where you could
write ActiveX components, COM DLLs, and full-fledged Windows
applications. I watched the whole history. I was there for it all.

I approached .NET with a lot of enthusiasm--and a lot of baggage.
There were things that I wanted to be able to do in VB6 that I *simply
could not do.* Or, if I wanted to do them, the amount of code that I
had to write was enormous, and I had to invoke obscure API functions
which, if I was not very careful, crashed my program (or, in the worst
case scenario, the user's machine.

At first, moving to .NET was difficult. I had to unlearn a lot of
things. But in the long run, it proved to be a worthwhile investment.
I haven't looked back since. These days, I'm loathe to work with VB6
code, and dread having to maintain our legacy VB6 code. I'd rather
port it .NET because the .NET code is more stable, easier to document,
and more secure.

There were a few things that VB6 had going for it:

- It was a great prototyping platform. You could whip things up in a
jiffy. The problem was, too many prototypes became production
software. I'm not whipping that out of my butt. I watched it happen,
time and again. "We'll just do the UI prototype in VB." Next thing you
know, the "prototype" is the application. (To this day, I refuse to
use development software to prepare UI prototypes. I do them in
Visio.)

- It was a great tool for experimentation. If you wanted to figure out
how to do something, or whether or not something was feasible, without
having to build a full framework, you could do it in VB6 in a few
minutes, and determine its feasibility. Sometimes, that's a lot harder
to do in .NET (though that's not always the case). And there's still
that problem that classic VB applications tend to become production
applications.

- When you NEEDED to ignore the data type of a variable, you could.
All the religous arguments aside, the Variant served a discrete
purpose when it came into being. It was an intrinsic part of COM, and
COM was created to solve a certain set of problems. And for a while,
COM solved those problems very well. Unfortunately, COM's
effectiveness was short-lived; DLL Hell ruined it. COM's problems,
however, are one of the key issues that led to many of the design
decisions in .NET.

- There was a plethora of available 3rd party components for it. That
doesn't mean they were all worth what you paid for, but the chances
were very high that you could find what you were looking for. And if
you couldn't find one, and you had the time, you could roll your own
control with a little time and careful coding.

Others will have their opinions about things that made classic VB a
great platform. Things like the fact that it was so easy to learn, it
was pervasive, it was affordable, you could find books about it just
about anywhere, the language was built into the Office suite, and so
on. But even with all of that, there were some fairly serious
drawbacks to it:

- Classic Visual Basic was never a truly type-safe language. Type-
safety is a critical part of writing secure code. It ensures that my
code doesn't write over someone else's memory. .NET is fanatical about
type safety.

- As useful as the Variant was, it was sometimes difficult to debug,
because it tended to be overused. Its abuse wasn't always intentional.
A lot of developers were self-taught; they didn't understand the
importance of Option Strict, which was a relatively late addition to
the language. Consequently, the default data type for many variables
was a Variant. This meant that many variables became Variants by
default and their data types were subject to spontaneous changes as
the software ran. These types of defects are notoriously difficult to
debug.

- Classic VB was never truly object oriented. It supported the
*notion* of objects--and COM's notion of objects, at that--but it
didn't support implementation inheritance, polymorphism, overloading,
or overriding. You had to do all of that yourself through delegation.
This created massive code libraries where reams of code simply
forwarded function calls to other functions. And VB's objects didn't
support constructors.

- The error handling system in VB was always (in my personal opinion)
kludgy at best. You could either use On Error Resume Next or On Error
GoTo. And trying to nest error handlers quickly got messy. Anyone who
didn't know how to properly handle errors was in for a whole world of
hurt.

So, along comes VB.NET. I have yet to run into anything that I could
do in classic VB that I can't to in VB.NET. Further, my code is more
secure is because it's type-safe; I don't have to hand-code calls to
the Win32 API anymore; structured exception handling is far superior
to the error handling in classic VB; I get full support for all of the
OOP principles, including objects with overloadable constructors; and
I still have a burgeoning supply of available 3rd party components at
my disposal.

In it's day, VB6 was a great platform, and I loved it. I swore by it.
I could write just about anything I needed to do in it. But bigger and
better things have come along. I haven't regretted the move to .NET.

I hope I have answered your question.





Mar 23 '07 #15

P: n/a
I find Mr. Balena to be very readable, and knowledgable. I really got a lot
ouf of his "Best Practices" book (in both C# and VB).

And I agree with Michael's post. After all, starting with something small
is the best way to figure it out.

And check out Deborah Kurata's book. It shows you how to do data binding
against objects, and once you have your classes set up, the UI stuff can be
pretty quick.

Good luck.
Robin S.
----------------------
"Aalaan" <ve*********@invalid.comwrote in message
news:46******@dnews.tpgi.com.au...
Not sure I'm going to make the move yet. It be all a bit beyond me and a
complete overkill for the applications I wish to write. But in passing I
notice you mention Francesco. I have just obtained Francesco's book about
vb6. Very useful.

"RobinS" <Ro****@NoSpam.yah.nonewrote in message
news:a7******************************@comcast.com. ..
>>
I agree with everything Mike says.

And I have to admit, being able to build the project and see *all* of
the errors and fix them before building again is great, and I love being
able to put in regions and being able to collapse and expand methods.
And does anybody else love code snippets, or is it just me? And data
binding! It actually works now! The thrill of it all!

It's those little conveniences that you really miss when you do .Net and
then you have to go back and maintain a VB6 application.

If you want some help moving up to .Net, I have some books to recommend.
The first is Deborah Kurata's "Doing Objects in VB2005". This explains
the 3-tier architecture (UI layer, business layer, and data access
layer), and how to implement it. You end up building a small
application. It's very pragmatic, and throws in some things like how to
store user settings, use code snippets and even write your own, access
SQLServer from Visual Studio, etc. This book really helped me a lot. And
I'm not just saying that because my quote about it helping me move from
VB6 to VB2005 is on the back of the book. :-)

The other one I read cover to cover was Francesco Balena's "VB2005: The
Language". It has a lot of info about VB6 versus VB2005. It only covers
the language, not the forms or data access.

For data access, I turn to Dave Sceppa's "ADO.Net: The Core Reference".
And if you're doing SQLServer, check out Bill Vaughn's book,
"Hitchhiker's Guide to Visual Studio and SQLServer".

I am really enjoying my .Net experience, and have had a great time
rewriting my VB6 stuff in .Net. I hope you do, too.

Robin S.
Ts'i mahnu uterna ot twan ot geifur hingts uto.
-----------------------------------------------
"Mike Hofer" <kc********@gmail.comwrote in message
news:11**********************@n59g2000hsh.googleg roups.com...
>>On Mar 22, 3:03 pm, "Aalaan" <veryinva...@invalid.comwrote:
I am presently a user of classic vb6 and hang out on those newsgroups.
Some
of you may be aware that there is a very anti MS and vb2005 feeling
there. I
have tried to get them to tell me which features of vb2005 are
actually
worse then vb6 in practice, and forget the philosophy of backward
compatibility for a moment.

I would now like to hear "the other side". Could *anyone who
previously used
vb6* (only those pleased; I feel the others will not be able to make
the
comparison) tell me if the move to dotnet was a good idea. Leave aside
the
needs of your workplace, future proofing etc. and say whether you
regret the
move or not, and the reasons for your answer.

Apologies if this is the wrong group. If it is, perhaps you'll tell me
which
dotnet group is the best one. Oh, and which is the best one for
beginners or
'converts'. Thanks v much

Hi Aalaan,

I started using Visual Basic with version 1.0. I've used every version
since then. I watched it go from its most basic version, which was
*extremely* rudimentary but enabled you to write very basic Windows
applications with no MDI support, to version 6.0, where you could
write ActiveX components, COM DLLs, and full-fledged Windows
applications. I watched the whole history. I was there for it all.

I approached .NET with a lot of enthusiasm--and a lot of baggage.
There were things that I wanted to be able to do in VB6 that I *simply
could not do.* Or, if I wanted to do them, the amount of code that I
had to write was enormous, and I had to invoke obscure API functions
which, if I was not very careful, crashed my program (or, in the worst
case scenario, the user's machine.

At first, moving to .NET was difficult. I had to unlearn a lot of
things. But in the long run, it proved to be a worthwhile investment.
I haven't looked back since. These days, I'm loathe to work with VB6
code, and dread having to maintain our legacy VB6 code. I'd rather
port it .NET because the .NET code is more stable, easier to document,
and more secure.

There were a few things that VB6 had going for it:

- It was a great prototyping platform. You could whip things up in a
jiffy. The problem was, too many prototypes became production
software. I'm not whipping that out of my butt. I watched it happen,
time and again. "We'll just do the UI prototype in VB." Next thing you
know, the "prototype" is the application. (To this day, I refuse to
use development software to prepare UI prototypes. I do them in
Visio.)

- It was a great tool for experimentation. If you wanted to figure out
how to do something, or whether or not something was feasible, without
having to build a full framework, you could do it in VB6 in a few
minutes, and determine its feasibility. Sometimes, that's a lot harder
to do in .NET (though that's not always the case). And there's still
that problem that classic VB applications tend to become production
applications.

- When you NEEDED to ignore the data type of a variable, you could.
All the religous arguments aside, the Variant served a discrete
purpose when it came into being. It was an intrinsic part of COM, and
COM was created to solve a certain set of problems. And for a while,
COM solved those problems very well. Unfortunately, COM's
effectiveness was short-lived; DLL Hell ruined it. COM's problems,
however, are one of the key issues that led to many of the design
decisions in .NET.

- There was a plethora of available 3rd party components for it. That
doesn't mean they were all worth what you paid for, but the chances
were very high that you could find what you were looking for. And if
you couldn't find one, and you had the time, you could roll your own
control with a little time and careful coding.

Others will have their opinions about things that made classic VB a
great platform. Things like the fact that it was so easy to learn, it
was pervasive, it was affordable, you could find books about it just
about anywhere, the language was built into the Office suite, and so
on. But even with all of that, there were some fairly serious
drawbacks to it:

- Classic Visual Basic was never a truly type-safe language. Type-
safety is a critical part of writing secure code. It ensures that my
code doesn't write over someone else's memory. .NET is fanatical about
type safety.

- As useful as the Variant was, it was sometimes difficult to debug,
because it tended to be overused. Its abuse wasn't always intentional.
A lot of developers were self-taught; they didn't understand the
importance of Option Strict, which was a relatively late addition to
the language. Consequently, the default data type for many variables
was a Variant. This meant that many variables became Variants by
default and their data types were subject to spontaneous changes as
the software ran. These types of defects are notoriously difficult to
debug.

- Classic VB was never truly object oriented. It supported the
*notion* of objects--and COM's notion of objects, at that--but it
didn't support implementation inheritance, polymorphism, overloading,
or overriding. You had to do all of that yourself through delegation.
This created massive code libraries where reams of code simply
forwarded function calls to other functions. And VB's objects didn't
support constructors.

- The error handling system in VB was always (in my personal opinion)
kludgy at best. You could either use On Error Resume Next or On Error
GoTo. And trying to nest error handlers quickly got messy. Anyone who
didn't know how to properly handle errors was in for a whole world of
hurt.

So, along comes VB.NET. I have yet to run into anything that I could
do in classic VB that I can't to in VB.NET. Further, my code is more
secure is because it's type-safe; I don't have to hand-code calls to
the Win32 API anymore; structured exception handling is far superior
to the error handling in classic VB; I get full support for all of the
OOP principles, including objects with overloadable constructors; and
I still have a burgeoning supply of available 3rd party components at
my disposal.

In it's day, VB6 was a great platform, and I loved it. I swore by it.
I could write just about anything I needed to do in it. But bigger and
better things have come along. I haven't regretted the move to .NET.

I hope I have answered your question.



Mar 23 '07 #16

This discussion thread is closed

Replies have been disabled for this discussion.