-
Alternatives for the old functions
Hi again..:wave:
When I try to code in VB2010, I usually unmark the reference to Microsoft.VisualBasic. Because I do not want to use the legacy functions of VB6. I want to complete walk in .Net path. :)
And I have found some alternatives for the old VB6 functions. But the rest not. :(
Where can I find the list of those methods or classes (alternatives for the VB6 functions) ?
(For eg: when I tried to find the difference of 2 dates, I couldn't find any other alternatives. So, I came back and used the Microsoft.VisualBasic reference for using DateDiff())
Is that a good practice to avoid using that reference ? :confused:
Thanks...:wave:
-
Re: Alternatives for the old functions
you can subtract 1 date from another in vb.net
-
Re: Alternatives for the old functions
Code:
Dim myStartDate As Date
Dim myEndDate As Date
Dim myTimeDiff as TimeSpan ' <-- Might need/want to look this class up in MSDN...
myTimeDiff = myEndDate - myStartDate
And that just about covers it.
-tg
-
Re: Alternatives for the old functions
Quote:
Originally Posted by
.paul.
you can subtract 1 date from another in vb.net
Quote:
Originally Posted by
techgnome
Code:
Dim myStartDate As Date
Dim myEndDate As Date
Dim myTimeDiff as TimeSpan ' <-- Might need/want to look this class up in MSDN...
myTimeDiff = myEndDate - myStartDate
And that just about covers it.
-tg
Thanks guys...:wave:
But what about this question:
Quote:
Is that a good practice to avoid using that reference ?
-
Re: Alternatives for the old functions
Quote:
Originally Posted by
akhileshbc
Is that a good practice to avoid using that reference ? :confused:
eventually microsoft will remove the methods in that class. so yes...
-
Re: Alternatives for the old functions
ok.. Thanks...:wave:
Any suggestions for this one:
Quote:
Where can I find the list of those methods or classes (alternatives for the VB6 functions) ?
...:wave:
-
Re: Alternatives for the old functions
-
Re: Alternatives for the old functions
I think your best bet is just to gather a few methods you don't know the .NET alternatives for and ask them here. I'm sure most of us know most of the alternatives quickly so it is most probably even quicker than looking it up in a book.
-
Re: Alternatives for the old functions
Quote:
Originally Posted by
.paul.
Quote:
Originally Posted by
NickThissen
I think your best bet is just to gather a few methods you don't know the .NET alternatives for and ask them here. I'm sure most of us know most of the alternatives quickly so it is most probably even quicker than looking it up in a book.
Thanks guys...:wave:
I'll ask for the alternatives here. :thumb:
-
Re: Alternatives for the old functions
Somewhere in the bowels of MSDN there's a really nice page that lists most of the VB6 functions and their .NET equivalents. I've found and lost this page several times over the past couple of years; I'm going to hunt for it for a while longer.
That said, it's a matter of personal opinion as to whether it's a bad practice to use the legacy functions. Some of the casts like CInt() are actually specially optimized by the compiler and can be faster than the more roundabout .NET conversion methods. On the other hand, there's a growing number of people (like me) that never used VB6 and have no idea how the VB6 functions work in general. Some are easy enough to figure out, but then there's complicated functions like DateDiff() that really require a lot of documentation diving to understand.
My rule of thumb when using a VB-specific method is to ask myself, "Is this clear to a person who doesn't use VB?" I make this distinction because my work is in C#, so even if I prototype something in VB .NET I need to ensure it will be clear to C# developers and painless to migrate. CInt() and AscW() clearly get to stay because in C# it's easy to interpret them as (int). DateDiff() is a clear off-limits method because other .NET developers would reach for DateTime.Subtract() or operators first.
There are a few notable exceptions. Microsoft.VisualBasic.FileIO.TextFieldParser is an incredibly useful class for parsing simple delimited files. It's useful enough that on occasion I've imported Microsoft.VisualBasic into a C# project so I could use it! The Microsoft.VisualBasic DLL also includes a customized version of System.Windows.Forms.Application that can be useful to C# applications that want single-instance functionality.
So I don't think it's always a bad practice, but it's definitely best to avoid legacy functions when there's a CLR technique that is more widely understood.
Now I'll get around to digging for that page again... I'm close but the tree can be such a pain...
-
Re: Alternatives for the old functions
Point of order... don't confuse the Microsoft.VisualBasic namespace with the Microsoft.VisualBasic.Compatibility.VB6 namespace. The former is the actual VB run-time namespace, while the latter contains the VB6 legacy function that is generally advisable to avoid.
So the TextFieldParser is part of the .NET code... while CInt() isn't. The clue is in the Fully Qualified Namespace (FQNS) ... Since the TextFieldParse resides in the VisualBasic namespace and not the Compatibility.VB6 NS, it's not part of the legacy base.
-tg
-
Re: Alternatives for the old functions
I used to draw a line by the namespaces, but lately I like to follow my guideline of asking whether a C# developer might be confused by it. The Microsoft.VisualBasic.Compatibility namespaces are *definitely* a danger though; a quick skim of that namespace shows it should only be used when you need something to work RIGHT NOW and don't really care if it's following .NET; a bad practice in itself. (Why change languages if you don't want to convert?) Nice warning sign: *everything* in the documentation is marked obsolete. If you see something documented as obsolete, that is Microsoft's warning that they just might delete it one day. If it's not marked obsolete, it's fair game for consideration by the rest of the heuristic.
CInt() is actually in Microsoft.VisualBasic.CompilerServices and is a member of the Conversions class; to be honest there is no real CInt() function at all because the compiler knows to convert that call into various highly optimized conversion methods. Why am I so sure? Microsoft suggests it might be more performant than other casts:
Quote:
These functions are compiled inline, meaning the conversion code is part of the code that evaluates the expression. Sometimes there is no call to a procedure to accomplish the conversion, which improves performance.
So your post is incorrect. CInt() is optimized in the VB .NET compiler and thus inseparable from VB .NET code. I don't think Microsoft.VisualBasic.dll is necessarily part of the CLR, but I think it's safe to assume that Microsoft won't drop support for a DLL on which one of their compilers depends *and* that they've encouraged programmers to use for years.
I also found the page I was looking for. Language Changes for Visual Basic 6.0 Users is where any changes between VB6 and VB .NET are supposed to be documented. Unfortunately, it seems a little to hasty to point you to things inside Microsoft.VisualBasic rather than the .NET equivalents, so I guess you're left with advice that's already been given: if you're curious if there's a non-VB-specific way to do something, ask.
-
Re: Alternatives for the old functions
I've been wondering if there's a .Net equivalent of the vb6 Mid() function and I'm not talking about the String.SubString() use of Mid() since vb6's Mid() lets you specify what that range of text is within the other string
Like so:
Code:
Dim SomeString As String = "1234567890"
MessageBox.Show(SomeString)
Mid(SomeString, 2, 4) = "abcd"
MessageBox.Show(SomeString)
'SomeString is now "1abcd67890"
You can't do the above with String.SubString(), so what's the equivalent .Net function for that?
Edit:
Also all the vb6 compatibility stuff is in the Microsoft.VisualBasic namespace since (at least in .Net 2.0 and older) Microsoft.VisualBasic.Compatibility isn't a namespace that exists
-
Re: Alternatives for the old functions
Substring. Seriously, it replaced Right, Left, and Mid. I'm not quite sure what you are seeing that you can't replicate with it.
-
Re: Alternatives for the old functions
Quote:
Originally Posted by
Shaggy Hiker
Substring. Seriously, it replaced Right, Left, and Mid. I'm not quite sure what you are seeing that you can't replicate with it.
You can't do that with SubString() though:
Code:
SomeString.Substring(1, 4) = "zykx"
That doesn't compile: "Expression is a value and therefore cannot be the target of an assignment."
-
Re: Alternatives for the old functions
The problem is .NET strings are immutable; once created they cannot be changed without creating a new one. This makes it impossible for the return value of Substring() to be reassigned, since it's returning a string object rather than a reference into an existing one and the assignment would just replace it.
The only way you're going to get a similar functionality is to treat it like an array of characters. Let's say you want to replace 4 characters at index 1. You have a few choices. You could Remove() then Insert():
Code:
input = input.Remove(1, 4)
input = input.Insert(1, "asdf")
I don't like that solution because it creates a lot of intermediate results. The System.Text.StringBuilder() class creates a mutable buffer of characters and is more efficient for this sort of thing:
Code:
Dim worker As New Text.StringBuilder(input)
worker.Remove(1, 4)
worker.Insert(1, "asdf")
input = worker.ToString()
StringBuilder introduces another alternative you might find more intuitive: you can replace characters in-place:
Code:
Dim worker As New Text.StringBuilder(input)
Dim replacement As String = "asdf"
Dim startIndex As Integer = 1
For i As Integer = 0 To replacement.Length - 1
Dim index As Integer = i + startIndex
worker(index) = replacement(i)
Next
input = worker.ToString()
On second thought, that's even worse.
I don't know that the syntax of VB .NET or the mechanics of .NET strings would allow for Mid() to work the way that it used to work.
Also, you can still use the compatibility namespace in VS 2010. It is targeted at .NET 2.0 but with some effort you can make it work with a 4.0 targeted project. Why you would go that far out of your way I don't know; odds are if you are using a wizard to convert a VB6 project you aren't too concerned with hitting a specific framework version. I'm not supporting this path, just pointing out that Microsoft.VisualBasic.Compatibility does indeed exist. Add a reference to it and all of its nastiness will be available.
-
Re: Alternatives for the old functions
I kind of doubt that it really worked that way even in VB6. The code worked, but I would be surprised if they just inserted into an existing string. More likely, there was a bit more work behind the scenes that resulted in a new string that included the changes. So you can probably perform the same action, you just can't do it in a single line of the same nature. The line would look worse, something like:
SomeString = SomeString.Substring(0,1) & "zykx" & SomeString.Substring(1)
or somewhat different, depending on what that old Mid was actually accomplishing.
-
Re: Alternatives for the old functions
Quote:
Originally Posted by
Sitten Spynne
The problem is .NET strings are immutable; once created they cannot be changed without creating a new one. This makes it impossible for the return value of Substring() to be reassigned, since it's returning a string object rather than a reference into an existing one and the assignment would just replace it.
Strings are immutable in all languages (that I know of), even Basic, QBasic, vb (1 through 6) and .Net
So when you do Mid(x, x, x) = "xxx", even in vb6, it produces a whole new string at that point.
Quote:
Originally Posted by
Shaggy Hiker
I kind of doubt that it really worked that way even in VB6. The code worked, but I would be surprised if they just inserted into an existing string. More likely, there was a bit more work behind the scenes that resulted in a new string that included the changes. So you can probably perform the same action, you just can't do it in a single line of the same nature. The line would look worse, something like:
SomeString = SomeString.Substring(0,1) & "zykx" & SomeString.Substring(1)
or somewhat different, depending on what that old Mid was actually accomplishing.
That's close, but Mid() doesn't insert, it replaces the part of the string at the specified index for the specified length. Which I don't actually do very often.
-
Re: Alternatives for the old functions
How the hell does that Mid function even work? ReSharper shows me that it is a static function returning a String in the Microsoft.VisualBasic.Strings class, but I can't see any way of implementing that syntax in .NET.
Whatever the Mid function returns isn't used because your "abcd" string is assigned to the result immediately.
Also, I don't see how the Mid function can use your "abcd" string, since it would have to run before the " = "abcd"" part would be executed, hence it would have no knowledge of that string yet.
I suppose it doesn't something special just like CInt and the If() operator, etc. That's all the more reason for me not to use it.
-
Re: Alternatives for the old functions
Mid function was great in VB6, you could define a buffer of say 20,000 spaces and then use mid to replace it bit by bit without (as it appears to look anyway) creating a new string. It was suuuuper fast to do this instead of concat each string. You could then just cut off what you didn't need after.
-
Re: Alternatives for the old functions
You can do the same thing with System.Text.StringBuilder, albeit with a sort of strange syntax. You can also create an array of Char objects and use the Array class's method to treat it like a buffer, then the String class's constructor that takes a Char array. It's a bit more roundabout, but it's still possible.
-
Re: Alternatives for the old functions
To clarify a few issues here:
1. "CInt", "CBool", etc. are not part of any namespace - they are part of the VB programming language, just like "True" and "False", so it doesn't make any sense at all to avoid these.
2. The "Mid" statement is very different from the "Mid" function and has no non-trivial replacement in any language. It also (like 'CInt') is not part of any namespace - it is part of the language. We use the following helper class to convert usage of the "Mid" statement in C#:
Code:
internal static class SimulateMidStatement
{
internal static void MidStatement(ref string target, int oneBasedStart, char insert)
{
if (target == null)
return;
target = target.Remove(oneBasedStart - 1, 1).Insert(oneBasedStart - 1, insert.ToString());
}
internal static void MidStatement(ref string target, int oneBasedStart, string insert)
{
if (target == null || insert == null)
return;
target = target.PadRight(target.Length + insert.Length).Remove(oneBasedStart - 1, insert.Length).Insert(oneBasedStart - 1, insert).Substring(0, target.Length);
}
internal static void MidStatement(ref string target, int oneBasedStart, string insert, int length)
{
if (target == null || insert == null)
return;
int minLength = System.Math.Min(insert.Length, length);
target = target.PadRight(target.Length + insert.Length).Remove(oneBasedStart - 1, minLength).Insert(oneBasedStart - 1, insert.Substring(0, minLength)).Substring(0, target.Length);
}
}
-
Re: Alternatives for the old functions
Thanks guys...:wave:
Great piece of information...:thumb:
-
Re: Alternatives for the old functions
Quote:
Originally Posted by
NickThissen
How the hell does that Mid function even work? ReSharper shows me that it is a static function returning a String in the Microsoft.VisualBasic.Strings class, but I can't see any way of implementing that syntax in .NET.
Whatever the Mid function returns isn't used because your "abcd" string is assigned to the result immediately.
Also, I don't see how the Mid function can use your "abcd" string, since it would have to run before the " = "abcd"" part would be executed, hence it would have no knowledge of that string yet.
I suppose it doesn't something special just like CInt and the If() operator, etc. That's all the more reason for me not to use it.
Why would you not use the ternary If() in vb? It's more compact than If... Else.. End If and it's much more efficient & strongly typed than the IIf() function.
I use If() all the time, when possible. Just like I use If Expression ? Val1 :Val2 in C# and Java.
-
Re: Alternatives for the old functions
Sorry I worded that wrongly lol. I do use If, very much actually. I don't use the old legacy VB6 functions that would no longer even work normally in .NET and they have to give them some special kind of treatment to get them to work the same way that they used to (like the Mid function).