 |
|
 |
I am using VWD2008 and I received message " The Visual Basic .net upgrade wizard is not installed on this computer" when I select the vb6 vbp project file (choice was vbp or vbproj). Is it avail or vwd?
Thank you Pauley
|
| Sign In·View Thread·PermaLink | |
|
|
|
 |
|
 |
If you were a little more than a VB programmer, you would know that "upgrading" code from one language to another is actually "porting".
|
| Sign In·View Thread·PermaLink | 4.00/5 (2 votes) |
|
|
|
 |
|
|
 |
|
 |
EDIT: before this starts to be a flame war, remember that I also program(med) vb6 and vb.net, so I'm not trying to flame vb devs!
He's harsh, but in essence right: vb.net just isn't the same, because it's better/more logically thought through and more oop. Different paradigms, different thinking, more able tools (inheritance, interfaces). Plus, your app will be easier to debug, etc. if you do it right from the start. If you don't embrace .NET techniques, you'll find yourself in trouble fast.
so, you're porting it in a new language (vb6 -> vb.net). don't think it's going to be easier, because it has vb in the name. we made that mistake.
take my word: it's easier to just port the stuff to C#... seriously, most programmers who have the guts to try new languages will end up with C#, because the keywords are the same, and it's the superior language. So why not learn C# instead of vb.net? It isn't more effort than learning vb.net, and it certainly won't harm your career!
I don't regret going from vb6 to vb.net, and I don't regret going from vb.net to C#. My only regret is not doing it sooner. Just try it!
|
| Sign In·View Thread·PermaLink | |
|
|
|
 |
|
 |
Why is there always someone who has to say C# is superior? Yikes! I can read it but I hate writing it. C# sure looks like code cause it doesn't look like anything a human would write. I really don't get sharpies.
What few apps we "converted" from VB6 we really just re-wrote. There were so many compromises made by the 2003 and 2005 upgrade wizards. Thanks for the article with your insights.
|
| Sign In·View Thread·PermaLink | |
|
|
|
 |
|
 |
Thank you for your comments.
One thing to think about when you are writing an article is, how will your readers find your article? A VB6 programmer that is looking for some information to help them through this process is much more likely to search by "Upgrade" rather than "Port", because they will be thinking "Upgrade from VB6 to VB.NET", thanks to Microsoft. Even the wizard is called an "Upgrade Wizard" instead of "Port Wizard".
As far as C# verses VB.NET... I am a C# programmer as well. There used to be a very strong case for C's superiority to VB. However, now that we are in the .NET era, the languages are very comparable. I personally prefer VB over C# (Hence "VBRocks"). But fortunately, you can now program in either, and still have interoperable assemblies.
|
| Sign In·View Thread·PermaLink | |
|
|
|
 |
|
 |
I like the article, but the comment about VB6... "VB.NET code in VB.NET runs good (VERY good), much faster than VB6 code runs in VB6"
How's that again? Any evidence there? I like VB.net as well, and I could certainly point to badly written VB6 code that ran slower than well written VB.net code, but that kind of general statement doesn't do anyone any good.
Also, although some VB6 commands +might+ have similar, ".net ish" constructs in .net, they often aren't the same.
Take Len() vs .Length Len() will always work exactly as any VB6er would expect it to, but .Length absolutely will not (it fails on uninitialized strings). So you have to be careful about blanket-converting many of the VB6 built in functions.
Just something to consider.
DarinH
|
| Sign In·View Thread·PermaLink | 5.00/5 (1 vote) |
|
|
|
 |
|
 |
Len() will always work exactly as any VB6er would expect it to, but .Length absolutely will not (it fails on uninitialized strings). So you have to be careful about blanket-converting many of the VB6 built in functions.
Correct. More generally, if one uses the VB6-style mid, len, etc. one generally doesn't have to worry about the distinction between a Nothing string and an empty one; when using the vb6-style functions, one can let strings default to nothing, but with the .net methods one must initialize them to empty. Given that strings are not an inheritable type (which should imply that none of the methods support overrides), I would think the system could always use the default string methods for any string variable, whether empty or not, but .net doesn't allow such a thing.
Also, note that vb.net string handling can be faster than VB6 if one uses objects like System.Text.Stringbuilder wisely, but can be much slower (over 10x) than VB6 if one uses string-handling code as-is.
BTW, is there any good replacement for the vb6-style "Collection" that does everything the Collection can do? It has some definite annoyances, but it also seems to have some unique features. For example, if the objects in a Collection have a "name" field which matches their name, one can easily code something like:
For Each Thing in myCollection If Thing.ShouldBeDeleted Then myCollection.Remove(Thing.Name) End If Next Nice, simple, and straightforward, and it works. None of the non-VB types offer such functionality; the only way I've found to perform such a function with them is to build a list of objects to be deleted and then delete those objects on a second pass.
I tried implementing my own class to mimic the functionality of the VB6 Collection object, but with the added benefits of generic support, a Contains function, etc. but the performance was nowhere near as good as the VB6 Collection object. Presently, I use Dictionary(of T) and handle purges by building a list of objects to delete, but that really seems a horrible way to do things.
I can understand a desire to have an enumerator throw an exception if the list is modified during enumeration in such a fashion that the enumerator would be unable to continue without trouble, or even if the list is modified in a way which could not consistently be performed without causing trouble (e.g. adding an item to a hash table could break things if the addition causes the table to expand, with existing objects getting arbitrarily resequenced; such a hash table should probably throw an exception if an object is added during enumeration, whether or not that particular addition triggered a rehash, unless the table would be able to ensure that previously-existing objects could still be read out correctly). Is there any good reason why data structures that would be capable of handling modifications during enumeration should not do so? The VB6 "Collection" is the only Microsoft iEnumerable data structure I know of that does.
|
| Sign In·View Thread·PermaLink | |
|
|
|
 |
|
 |
The vb6 collection was a sorry excuse for a collection. You had to write your own collection to wrap it, to check if items existed, etc. and to make it sort-of typesafe.
The vb.net collection(s) have the annoyance of deleting elements, but other excellent methods and are infinite times more robust/type safe. Plus, much less boilerplate code...
Anyway, my point is that you don't want to mimic vb6 collections. But you have to use the .NET way of thinking to get all the benefits. Also, all our ported applications run smoother in .NET.
Also, I think the distinction between null and "" is better/I'd rather be bugged by that and have proper oop. It's your "old" way of thinking, which unluckily can't and shouldn't be "ported" to .NET. No offence, I know it takes time to change the way you code!
Good example: The "DoEvents" issue. In .NET, you can finally use threads, so use them, and forget DoEvents.
|
| Sign In·View Thread·PermaLink | |
|
|
|
 |
|
 |
TF_Productions wrote: The vb6 collection was a sorry excuse for a collection. You had to write your own collection to wrap it, to check if items existed, etc. and to make it sort-of typesafe.
It was in many ways a pretty sorry excuse for a collection, but it also had some unique features. I wonder why Microsoft didn't provide any nice .net type that included them?
|
| Sign In·View Thread·PermaLink | |
|
|
|
 |
|