Re: Back to VB6 and .NET

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

On Feb 6, 3:49 pm, "Ken Halter" <Ken_Halter@xxxxxxxxxxxxxxxxxxxxxxxxx>
wrote:

Because it was an afterthought, hacked into place in a desparate attempt to
grab more VB Classic devs.

I don't where you think it is a hack. Works slightly better (can make
more types of changes) on my computer editing the same type of
project.

Try it in VB5/6. There is *no* noticable time delays between keystrokes.

No performance difference here. There are situations where I can make
VB6 bog down depending on the mix of projects I load and what section
I am editing. VB6 Edit and Continue isn't perfect.

..NET edit and continue works and is SLIGHTLY better than VB6's Edit
and Continue. It is slightly better because you can edit more
under .NET than VB6 and you have better debug utilities.

Can VB6 do stuff B# can't? Most likely
(especially if we're talking performance and ease of use). The problem is in
the name. Period. When they released dotNet, there were 24 letters they had
to choose from (26 - C and B). Instead of picking another letter, they
re-used "B" and called their new language VB... the problem is, it does
*NOT* recognize BASIC syntax. Some? Sure.... the simple fact that you can
load VB3 code into VB6 and, if there are no dependencies, simply hit the Run
button, should tell people that B# is *NOT* BASIC.

1) B# as you like to call it has met and exceeded VB6's capabilities
in all areas since VS 2005. I worked with Visual BASIC since 1993 with
a CAD/CAM application that push its limits. The release of VS 2005
implemented the remaining features of VB6 that were missing.

2) B# is BASIC, I agree it is NOT VB Classic of VB 1 to 6. But it is
BASIC.

Trying to sink VB.NET on technical merits is beating a dead horse. The
problem continues to be the lack of BACKWARDS COMPATIBILITY. Bitching
about non existant technical issues is going give .NET proponents
reasons to ignore because you come across like a person who doesn't
know what the hell they are talking about.

The difference with me is that I continue to use VB6 on a serious
project while implementing that same project on .NET along with making
new Projects in .NET.

Here is how it went down for me.

Visual Studio .NET 1.0 - Nice stuff but MS you are are joking that
this is a successor to Visual Studio 6.

Visual Studio .NET 2003 - Gee you still didn't get it right.

Visual Studio .NET 2005 - Well damn it finally works right. Backwards
compatibility is still shit but COM Interop works a lot a lot better.

Visual Studio .NET 2008 - Now we are cooking. Finally getting updates
that are all improvements instead of making up for lost time. The
built-in unit testing is the best new feature in my opinion.

Aside from new project I have a new EXE running on top of the same
ActiveX DLLs complied with VB 6. This EXE is used mainly to run unit
tests. Plus I have a conversion project of the ActiveX DLLs in VB.NET.
Since 2005 there are hasn't been any major problems other than usual
issues of converting one language over the another. Plus I have a
Mono only project I use to make sure I don't wind up locking myself
into MS.

My plan is to do a top down conversion starting with the EXE and
working down to the core Active X DLLs.

The features of .NET that give an order of magnitude improvement in
development are
1) the fact you don't have to worry about break binary compatibility.
2) Refactoring tools are available and just work in the IDE.
3) Generics plus inheritance dramatically reduce the amount of
boilerplate code.

Again the issue is one of Backwards Compatibility not technical merit.
.

Relevant Pages

  • Re: (1/2 OT) Reasons to begin with .Net
    ... As for Edit and Continue VB.NET has had that since 2005. ... Sure it makes it easy for people to just run the thing and attempt to patch while running, but that's really mroe a symptom of poor tooling, poor testing and lack of a bakcground compiler that cause the reliance on E&C in VB6. ... but they made a lot of improvements since then and so too has hardware drastically improved since then. ...
    (microsoft.public.vb.general.discussion)
  • Re: Visual Studio Professional Edition purchase
    ... In the latter three you are in fact creating forms and things like that almost exact in the same way as you did with VB6. ... Beside that there is in Visual Studio the original C++ as it was in Visual Studio 6 using MFC. ... It is not my goal to start a discussion, so if you should go to a C language is your own decission and it is never wrong to learn both languages. ... and HTML (if you can call HTML programming). ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Most Economical VB Development Compiler
    ... primary objective is to be able to compile code that was written for vb6 ... Is there a Service Pack Level to prefer in the Visual Studio 6 Enterprise ... If the package I end up buying was at an older Service Level, ...
    (microsoft.public.vb.winapi)
  • Re: VS2008 vs VS2010, anyone used it?
    ... Is this the bug you refer to?: ... Visual Studio Product Team ... I'm a Developer here at Microsoft on the Visual C++ IDE team. ... What "edit and continue" bug? ...
    (microsoft.public.vc.mfc)
  • Re: Mysteriously Caught Exceptions
    ... But it is not that fact alone which dictates that it is not the correct group for VB.Net questions, it is the fact that VB.Net is not in any way backwards compatible with VB6 code and it is the fact that because of this breaking of backwards compatibility Micro$oft have created a new and completely different newsgroup for VB.Net. ... Naturally, because they are usually "newbies", they would become confused if that is all we did because they would see "VB" in the name of both groups and they would wonder what they did wrong, so personally I usually add a few notes telling them a little about why there are two groups for what might otherwise be seen by them as one programming "language", so that they will know that they are in fact completely different, which is why they have completely different newsgroups. ...
    (microsoft.public.dotnet.languages.vb)