I am working on migration of VB6 Application to VB.net.
the VB6 code uses ChrB quite often and I need to know how to convert it into vb.net
has anyone faced any similar issue..?
Regards,
Rasheed
VB.NET doesn’t support “byte-oriented” string methods.
VB Migration Partner provides the ChrB6 replacement method, which approximates the original VB6 method’s behavior but isn’t guaranteed to work well in all circumstances. This replacement method is marked as obsolete and methods invocations are flagged with a migration warning.
Related
Is the syntax for VBScript and VB.NET exactly the same?
Specifically, would a syntax parser for VB.NET work for VBScript?
No, they are not the same.
vb.net is a jit-compiled strongly typed object oriented language that runs on the .net framework; vbscript is interpreted. Syntax is different in many subtle ways, mostly relating to scoping and the keywords necessary for vb.net to support true object oriented concepts that vbscript just doesn't have.
No, the syntax for VBScript is very similar to pre-.NET Visual Basic (i.e., VB6). VB.NET is completely different. But even compared to VB6, VBScript is still watered down.
No, the syntax for vbscript and vb.net are not exactly the same.
What reasons are there to migrate from vb.net specific language to .net framework language?
Examples:
VB.net
ubound
msgBox
.Net Framework
array.getUpperBound(0)
messageBox
Those functions exist to mirror the built-ins in VB6, to make porting code easier.
The functions in the Microsoft.VisualBasic namespace are often then wrappers around the .Net functions, with some additional checks before calling the function, so there's a minor performance hit using them vs. the native ones.
backward compatibility
VB.Net is a ".net framework language". The examples you showed for .Net work just fine in VB. So, in that sense you would not be migrating from anything. As to why you should prefer the newer .net idioms over the older vb-specific idioms, there are many reasons:
The newer code is more portable
It uses more modern programming concepts, and therefore subtly encourages better habits
The newer code is sometimes faster
The newer code has more features. For example, you can set more styles on the new MessageBox than you can the old MsgBox.
Sometimes neither is the best choice. For example, if you're using arrays much at all in .Net 2.0 and later you're doing something wrong. IEnumerable(Of T) and the various generic collection types are much to be preferred.
In Ironpython site exists references to a language called VBx using DLR. But i can't find any reference to this in google. Where is it?
Edit: Is a Implement of Visual Basic 6.0 in DLR? if yes is so cool. Is more expected for people using VB6 yet and can't migrate because big frameworks.
From this mailing list post:
VBx was an implementation of Visual Basic on the DLR. It was first meant
to be in Silverlight, but the VB team decided they'd rather put VB.NET in
Silverlight rather than build a new implementation up from scratch. So, VBx
is on hold.
Apparently it's an implementation of VB in the DLR:
http://www.mail-archive.com/users#lists.ironpython.com/msg05933.html
Straight from the mouth of Paul Vick (long time VB architect)
What is VBx?
VBx was one of the four language implementations that were originally driving the design of the DLR, the other three being IronPython (from which the DLR was extracted in the first place), IronRuby and Managed JavaScript.
VBx was intended to be a dynamic version of Visual Basic.NET or a .NET version of Visual Basic 6, whichever way you want to look at it. It was primarily intended as a testbed for the flexibility of the DLR, secondarily as a testbed for a more dynamic version of VB.NET and tertiarily (is that a word?) as a scripting language for Silverlight. It has fulfilled its primary goal and the designers of VB.NET decided that they want to pursue goals two and three within the existing VB.NET language, rather than producing yet another slightly different incompatible version of VB. (You already have VB.NET, VB, VBA and VBScript.)
Managed JavaScript was also abandoned, the team was folded into the IE team and is responsible for the ECMAScript 5 engine in IE 9.
I know .Net and C# pretty well, but never even looked at VB.
My problem is: our Win32 COM library is used by a number of clients, and we see that the number of failures is higher for those who use the library from VB (both VB and VB.NET) than for those who use C++, C# or Delphi. One thing about our library is that it is supposed to be used from one thread only - can some threading magic by VB be the cause of failures?
Clients tell us the do not create any extra threads on their own.
VB.NET = C# with a little different syntax. Seriously, you can translate VB.NET into C# line-for-line 99% of the time. Neither language creates threads under your nose without you knowing about it.
At most, if your clients are using VB.NET with Option Strict Off, then VB.NET's late-binding can cause more problems than it fixes -- its hard to know for sure without seeing the actual exceptions you're clients are reporting. In any case, chalk your clients failures up to less skillful programmers and bugs in their own library, not to your code or Microsofts implementation of VB.NET.
By magic, no. VB.Net will not do any extra threading under the hood. In this respect it's the same as C#.
VB6 and earlier can impact threading because all of it's objects will be STA COM objects. This won't add any threads to your program, but merely restrict the manner in which the VB6 objects can be accessed.
One case is Finalize methods. The CLR calls them from background thread(s) associated with the garbage collector part of the system. Most likely, your users should just not be calling your component from within Finalize.
Also watch for the BackgroundWorker or delegate BeginInvoke. Although the user does not create "any extra threads on their own", these mechanisms executes code on a thread pool thread separate from the main GUI thread.
I am working on a VB.NET WinForms app that was "upgraded" by Visual Studio (originally 1.0 or 1.1) from VB6 code (which was itself upgraded from VB5). Except for the few new forms I've created since taking over maintenance of this app, all of the forms in the application have a method called DefInstance which allows you to grab an in-memory copy of the form if there is one. What I can't figure out is why: when would I ever need to reference a form object in memory when it's not immediately in scope where I'm working. To my mind this violates all kinds of sound programming principles and seems like an invitation for memory leaks or worse.
The questions: (1) is this DefInstance thing an merely unfortunate remnant of the VB6 heritage of this app, and (2) should I make a point of removing DefInstance methods throughout the application?
I received this answer from a Microsoft employee:
http://msdn.microsoft.com/en-us/library/aa289529(VS.71,printer).aspx
In short, DefInstance is a "not best practices" compatibility method for older apps that haven't been made into true .NET WinForms apps. Being a web programmer until earlier this year I had never worked with VB6 "WinForms" applications nor had to deal with the compatibility compromises that the upgrade wizard makes in forcing them into .NET.
Yes, the default instance is a terrible byproduct of importing the application through the upgrade wizard. Using the default instance was a VB habit in pre dot net versions because forms were always resident in memmory as a default instance, although you could also g=create additional instances.
As Parvenu74 said, it is not a best practise. That being said, you should be very careful when removing it from an imported application because of side affects and references where it might be being used. Your best bet is to not use it in new code that you develop and slowly migrate yourself away from the "converted" code over time. As was mentioned above the default instance stuff was re-instroduced in VB 2005, but it's use is highly discouraged.
As you mention, it lets you get a reference to the form.
I've seen lots of VB written like this:
Private Sub Command_Click()
Call DoStuff
End Sub
Private Sub DoStuff()
Form1.myTextbox.Text = "Bad Idea"
End Sub
DefInstance allows DoStuff() to continue working without passing controls around.
See here: http://social.msdn.microsoft.com/Forums/en-US/vbgeneral/thread/6d7985b5-6db6-47a8-9e11-cbf114a48d37/ for more info.
Sadly, that toxic bit of syntactic sugar was added to VB8 (VS2005). Now fatally confusing VB.NET programmers when they can't comprehend that each thread has a separate instance of "Form1". The good news: now you definitely don't need DefInstance anymore.