|
|
Thanks a lot man, great article, especially about using the command prompt to migrate the code.
|
|
|
|
|
Microsoft have announced:-
Test existing apps for compatibility and delight new users by updating your app to Windows 10
Windows is committed to compatibility. The Windows compatibility team has been looking at user telemetry and reacting to feedback from Windows Insiders to ensure that existing apps work well with Windows 10. Windows 10 is designed to run Windows 8.1 and Windows Phone 8.1 software programs. And yes, everyone’s favorite VB6 Runtime will continue to work, too.
And there is an installer to help you install the VB6 programming IDE on Windows 10...
http://nuke.vbcorner.net/Articles/VB60/VisualStudio6Installer/tabid/93/language/en-US/Default.aspx[^]
|
|
|
|
|
With Microsoft confirming support for Visual Basic 6 (VB6) programming until 'at least' 2024 there doesn't seem any need to migrate.
Update or open source the Visual Basic 6 (VB6) programming language.
|
|
|
|
|
Fortunately, in 2014 VB6 has become popular again, so porting is not really necessary because a new version of VB6 is on the horizon 
|
|
|
|
|
I really hope this happens. I've been porting several Apps to VB.Net, but would love to have a modern version of VB6. VB.Net is just to big and clumsy, and holds VB programmers back.
|
|
|
|
|
|
3. Add 2 lines of code before the intensive processing begins to set the thread priority:
SetThreadPriority(GetCurre<wbr />ntThread, THREAD_PRIORITY_HIGHEST)
SetPriorityClass(GetCurren<wbr />tProcess, HIGH_PRIORITY_CLASS)
etc, and also in other lines as well.
|
|
|
|
|
Hi,
I want to upgrade/migrate (Target Framework 4.0) VB6 projects which contain more than 100,000 LOC (VB Group). I need your valuable feedback to whether I upgrade/migrate the code or write a newer application in .net. The VB6 application includes many third party controls/components.
Best regards,
Jawad
Jawad Munir
|
|
|
|
|
Good day. I sent you a post on an older project you created. Your slide show project. Could you check it and hopefully get back to me? thanks
|
|
|
|
|
Where do you put the following codes? Would you explain more detail about the codes?
"4. Use DoEvents() sparingly! Calling DoEvents() has a big performance hit, so use it sparingly."
Dim iLoops As Integer = 0
Do Until iLoops = 10000
'Calling DoEvents() every 500 loops will greatly increase application performance
If iLoops Mod 500 = 0 Then DoEvents()
iLoops += 1 'Add 1 to iLoops
Loop
Thanks.
|
|
|
|
|
Well basically, Visual Basic DoEvents() is a method that is called to give the processor a chance to do something else (like handle key strokes, or refresh your form). You don't usually need to use the DoEvents() method.
An a good example of when you would want to use the DoEvents() method is when you are reading in a large file. If you don't use the DoEvents() method, your program can just lock up until processing is done, which could be a 15 seconds, or could be 5 minutes or more. Here's an example of that:
'Path to a file
Dim path As String = "C:\Temp\MyFile.txt"
'Open file for reading
Using reader As New IO.StreamReader(path)
' stores the line being read in
Dim inLine As String = String.Empty
'read the file in
Do While reader.EndOfStream = False
inLine = reader.ReadLine()
Application.DoEvents()
Loop
End Using ' reader
If you still don't fully understand how it works, then do this: Add a button to a form, and double-click on it to go to the code window. Enter this code in Button's Click event, then start the program and click the button to see what happens.
Private Sub Button1_Click(ByVal sender As System.Object,
ByVal e As System.EventArgs) Handles Button1.Click
Do
Loop
End Sub
|
|
|
|
|
Hello,
¿have you solved the issue from converting the easy datareport generator to vb.net?
I've a lot of datareport without dataenvironment (I use disconnected records, customizable SELECT's, etc.)
Crystal Reports included is hard to use to me and I think it doesn't have the features I need.
¿Are there any class, or method for easy converting my custom datareports for some of the vb.net (.NET 2.0) things?
|
|
|
|
|
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
|
|
|
|
|
If you were a little more than a VB programmer, you would know that "upgrading" code from one language to another is actually "porting".
|
|
|
|
|
"Upgrading" is what Microsoft calls it. Stop splitting hairs and go troll somewhere else.
|
|
|
|
|
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!
|
|
|
|
|
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.
|
|
|
|
|
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.
|
|
|
|
|
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
|
|
|
|
|
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
NextNice, 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.
|
|
|
|
|
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.
|
|
|
|
|
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?
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
