vb.net upgrade: VB6 ---> VB.Net -- vb.net upgrade

You're in the

vb.net upgrade

group:

VB6 ---> VB.Net

Martin
6/1/2005 12:00:00 AM

vb.net upgrade:

We're still researching the consequences this upgrade will have on our apps.
And frankly, the more I read about it, the less attractive it seems. I read
on the Microsoft
site on this subject a few things that are no longer supported in Vb.Net.
Ranging from something trivial as the line control. (I'm sure we used a few
of those) to the OLE Container.
Why the heck did they scratch these things? And more importantly, does
anyone know of a decent substritute, especially for the OLE Container?

TIA,
Martin

Re: VB6 ---> VB.Net

Earl
6/1/2005 7:10:44 AM

It's not an "upgrade", it's a different philosophy.

[quoted text, click to view]

Re: VB6 ---> VB.Net

Martin
6/3/2005 12:00:00 AM

That's nice, but I still need to upgrade my apps...

[quoted text, click to view]

Re: VB6 ---> VB.Net

Michael D. Ober
6/3/2005 7:06:43 AM

Why upgrade an application that's working and doesn't need changing. If you
have to make major changes to an application, then upgrade it. Otherwise,
use the fact that VB 6 and VB 8 will coexist as both development and runtime
environments on the same system. BTW, don't bother with VB 7 or 7.1 (.net
2002 and 2003) as the VB IDE is a major step backwards from the VB 6 IDE.

Mike Ober.

[quoted text, click to view]

Re: VB6 ---> VB.Net

Earl
6/3/2005 9:27:43 AM

The point that I was making is that VB.Net is based on a disconnected data
access model, whereas VB is based on a client-server model. It is important
to start thinking with the new paradigm in mind before moving an app to
..Net, as the code from VB6 is not really "upgradeable" to VB.Net (despite
the existence of an upgrade utility). As you may have already heard, "VB.Net
aint really VB", simply a woefully misguided concatenation of the initials
"VB" with .Net, probably created by Microsoft to suck along the VB
developers. It could've been called anything (B# mebbe?) but it's
relationship to VB6 is not as close as the term would have you think (for
that matter, ADO.Net "aint ADO" either).

[quoted text, click to view]

Re: VB6 ---> VB.Net

Earl
6/3/2005 9:30:32 AM

I agree with the first part about not upgrading an app that is working and
doesn't need changing.

But about the IDE, I strongly disagree. While I'm near the front of the line
to slam Microsoft when they deserve it, in this case, they created a most
spectacular IDE that is a joy to work with. It is lightyears superior to the
VB6 IDE (and wait till you see the VS2005 IDE, another vast improvement). My
hat is off to Microsoft for the .Net Visual Studio IDE, no matter how much I
dislike the term "VB.Net".

[quoted text, click to view]

Re: VB6 ---> VB.Net

Michael D. Ober
6/6/2005 12:34:35 PM

Sorry, I wasn't clear. I consider the lack of Edit & Continue in the VB
2002/2003 IDE to be a serious lack. Even the old DOS DEBUG had this
feature. I wholeheartedly agree that the VB 2005 IDE is superior to the VB
6 IDE in most ways. The only real issue is the handling of collection
members - you can't see the contents of the members in the local window.

Also, the .NET 2.0 class library is one of the most complete class libraries
I've ever seen and using generics eliminate the entire issue of creating
strongly typed collection classes. Now if the VB.Net developers would bring

Dim colMyType as New Collection(of MyType)

into the language as syntactic sugar for

Dim colMyType as New System.Collections.Object...

Mike Ober.

[quoted text, click to view]

Re: VB6 ---> VB.Net

Michael D. Ober
6/6/2005 1:57:04 PM

I use the Imports statement already.

Mike.

[quoted text, click to view]

Re: VB6 ---> VB.Net

Jay B. Harlow [MVP - Outlook]
6/6/2005 2:47:14 PM

Michael,
| strongly typed collection classes. Now if the VB.Net developers would
bring
|
| Dim colMyType as New Collection(of MyType)
|
| into the language as syntactic sugar for
|
| Dim colMyType as New System.Collections.Object...
Already done.

Have a look at the Imports Statement.

---x--- cut here ---x--- sample.vb ---x---
Option Strict On
Option Explicit On

Imports System.Collections.ObjectModel

Public Module MainModule

Public Sub Main()
Dim colMyType as New Collection(of MyType)

End Sub

End Module
---x--- cut here ---x--- sample.vb ---x---

Alternatively you can use Project level Imports to avoid putting Imports in
each source file...

I normally inherit from Collection(Of T), something like:

Public Class MyTypeCollection
Inherits Collection(of MyType)

... methods that are truly unique to MyTypeCollection
... very few are needed ...

End Class

Hope this helps
Jay

[quoted text, click to view]
| Sorry, I wasn't clear. I consider the lack of Edit & Continue in the VB
| 2002/2003 IDE to be a serious lack. Even the old DOS DEBUG had this
| feature. I wholeheartedly agree that the VB 2005 IDE is superior to the
VB
| 6 IDE in most ways. The only real issue is the handling of collection
| members - you can't see the contents of the members in the local window.
|
| Also, the .NET 2.0 class library is one of the most complete class
libraries
| I've ever seen and using generics eliminate the entire issue of creating
| strongly typed collection classes. Now if the VB.Net developers would
bring
|
| Dim colMyType as New Collection(of MyType)
|
| into the language as syntactic sugar for
|
| Dim colMyType as New System.Collections.Object...
|
| Mike Ober.
|
[quoted text, click to view]
| > I agree with the first part about not upgrading an app that is working
and
| > doesn't need changing.
| >
| > But about the IDE, I strongly disagree. While I'm near the front of the
| line
| > to slam Microsoft when they deserve it, in this case, they created a
most
| > spectacular IDE that is a joy to work with. It is lightyears superior to
| the
| > VB6 IDE (and wait till you see the VS2005 IDE, another vast
improvement).
| My
| > hat is off to Microsoft for the .Net Visual Studio IDE, no matter how
much
| I
| > dislike the term "VB.Net".
| >
[quoted text, click to view]
| > > Why upgrade an application that's working and doesn't need changing.
If
| > > you
| > > have to make major changes to an application, then upgrade it.
| Otherwise,
| > > use the fact that VB 6 and VB 8 will coexist as both development and
| > > runtime
| > > environments on the same system. BTW, don't bother with VB 7 or 7.1
| > > (.net
| > > 2002 and 2003) as the VB IDE is a major step backwards from the VB 6
| IDE.
| > >
| > > Mike Ober.
| > >
[quoted text, click to view]
| > >> That's nice, but I still need to upgrade my apps...
| > >>
[quoted text, click to view]
| > >> > It's not an "upgrade", it's a different philosophy.
| > >> >
[quoted text, click to view]
| > >> > > We're still researching the consequences this upgrade will have
on
| > >> > > our
| > >> > > apps.
| > >> > > And frankly, the more I read about it, the less attractive it
| seems.
| > >> > > I
| > >> > > read
| > >> > > on the Microsoft
| > >> > > site on this subject a few things that are no longer supported in
| > >> Vb.Net.
| > >> > > Ranging from something trivial as the line control. (I'm sure we
| used
| > > a
| > >> > > few
| > >> > > of those) to the OLE Container.
| > >> > > Why the heck did they scratch these things? And more importantly,
| > >> > > does
| > >> > > anyone know of a decent substritute, especially for the OLE
| > >> > > Container?
| > >> > >
| > >> > > TIA,
| > >> > > Martin
| > >> > >
| > >> > >
| > >> >
| > >> >
| > >>
| > >>
| > >
| > >
| > >
| >
| >
| >
|
|
|

Re: VB6 ---> VB.Net

Earl
6/6/2005 8:15:52 PM

Simply, you have an in-memory dataset on each user's PC and make a
connection ONLY at the time each is retrieving or updating data. Regardless,
no matter whether a client functions in a fully connected or disconnected
scenario, the actual update must occur at a different moment in time.

[quoted text, click to view]

Re: VB6 ---> VB.Net

Tym
6/6/2005 9:01:26 PM

On Fri, 3 Jun 2005 09:27:43 -0500, "Earl" <brikshoe@newsgroups.nospam>
[quoted text, click to view]

As an existing vb6 programmer in DAO (yes - you read that right!) I'm
tinkering with vb.net 2003, and have the nest of 2005 but not yet
installed!

The disconnected recordset idea of ado.net worries me as I don't
really understand how two people cannot updatge the same record at the
same time if two clients are using disconnectedc recordsets.

Can someone explain please?

Tym

Re: VB6 ---> VB.Net

Tym
6/7/2005 7:58:13 AM

On Mon, 6 Jun 2005 20:15:52 -0500, "Earl" <brikshoe@newsgroups.nospam>
[quoted text, click to view]

Thanks for that.

However, doesn't that mean that two clients could read the same data,
make different changes, and the last client to update the recordset
would be the "one to win"? ie. the first client's changes would be
overwritten by the second??

Re: VB6 ---> VB.Net

Earl
6/7/2005 11:19:08 PM

Well, actually, you are veering into an issue that is always a possibility
when more than one person tries to update the same record, that is, the
issue of concurrency. ADO.Net uses optimistic concurrency during an update,
so the scenario you speak of is always possible, but there are techniques
for dealing with failed update attempts, including using the merge method to
import new "original values" to a failed row (see David Sceppa's excellent
book ADO.Net Core Reference for a discussion of this).

[quoted text, click to view]

Re: VB6 ---> VB.Net

Tym
6/8/2005 12:00:00 AM

On Tue, 7 Jun 2005 23:19:08 -0500, "Earl" <brikshoe@newsgroups.nospam>
[quoted text, click to view]

I also found this:

http://www.bridgeport.edu/sed/projects/cs597/Fall_2001/dkiran/chapter6.html

Re: VB6 ---> VB.Net

Gene Koesling
7/22/2005 4:00:34 PM

I think this is a good thread in which to post this... I poked around at the
msdn site for a few hours without finding an answer so I thought I'd try
here.

I've been working in numerous languages (C++, C#, Java & VB) for a number of
years. I've been teaching (college level) programming in C++ (v4-.Net) and
VB (6&.Net) as well. Recently returned to the workforce where I'm primarily
working in VB6. This morning my boss finally broke down and let me install
VB.Net (2002 standard edition) and asked me to start bringing a lot of the
company's apps up to .Net. No sooner did I try than I started running into
problems.

Prior to working here I've been using strictly Professional or Enterprise
editions of Visual Studio (most often under an educational license) and it
was always just a matter of opening a legacy project in VS.Net and the
conversion was pretty much automatic. Not so in this case, it seems this
version doesn't have the migration tool built into it.

What is the cheapest version of .Net I can get that has the migration tools
built into it? OR is there an inexpensive (or free) third-party tool that
can be used to port projects?

Note: I have enough experience to recognize that migration tools aren't the
be-all end-all - I've converted enough projects to know what else needs to
be done. I just want to speed the process as much as possible.

TIA,
GEAK

Got something to say? Click here to post a reply to this thread.

Don't see what you're looking for? Try a search.

View other messages in the vb.net upgrade group.

home · blog · groups

Questions? Comments? Contact the dn