VB Runtime Functions

A great many people still use VB Runtime functions in their code, i.e. functions like MsgBox and InStr that have been ported over from VB6. A great many of these are completely useless in that they simply reproduce functionality that is provided as or more easily in the Framework. There are those that do add some value in some cases, but most would not be missed in terms of functionality at least.

It's my opinion that these functions were probably included in VB.NET to make the legions of disgruntled VB6 developers feel more comfortable when making the switch. It's also my opinion that the vast majority of people who use these functions are either ex-VB6ers themselves or have learned from one.

I always recommend to people to avoid such functions unless they genuinely add value. MsgBox is a prime example of a function that I think should never be used. Many others who recommend not using them cite the fact that they may be deprecated in a future version as one of the reasons.

My question to the VB team (finally) is this: what is your position (official, or personal if you care to give it) on using these functions and is there any likelihood that they will be dropped from the Framework at any point in the foreseeable future?

lol, I was going to ask this question too. So I second the question and hope if will be left out of a not too distant .net framework version. It will probably only hinder the advancement and perception of VB.NET as a powerful professional development language.

Quote:

---

MsgBox is a prime example of a function that I think should never be used.

---

No doubt about it, MsgBox in some cases causes the code around it to behave incorrectly.
I actually got a rep point once for pointing out that someones code was'nt working because they were using MsgBox.
Ironically the MsgBox, was being used to test to see if the code worked.

I was thinking about asking this too. I'm really anxious to get an answer for this:)

Some of those.... MsgBox being one.... is nothing more than a wrapper for the actual .NET call.... Some are actual re-implementations of the original VB6 version (Instr comes to mind.... I don't think it actually calls the string.substring function)... but that's based on a (now) fuzzy memory.

-tg

Quote:

---

Originally Posted by techgnome

Some of those.... MsgBox being one.... is nothing more than a wrapper for the actual .NET call.... Some are actual re-implementations of the original VB6 version (Instr comes to mind.... I don't think it actually calls the string.substring function)... but that's based on a (now) fuzzy memory.

-tg

---

They're all reimplementations of VB6 versions. They exist specifically to behave exactly as they did in VB6. Whether they use types and method that you would normally use yourself is generally an indication of how quirky the VB6 behaviour is compared to what you would usually do yourself in VB.NET. I guess that might be a justification for their existence: converted VB6 code would be more complex to maintain the same behaviour without those functions. That's not a justification for using them in new code though, which is what most of us try to discourage.

I think they were available to make the transition for VB6 programmers easier. Plus the conversion issue that jmcihinney explained above.

Quote:

---

Originally Posted by Paul M

I think they were available to make the transition for VB6 programmers easier.

---

That's exactly what I said.

Quote:

---

It's my opinion that these functions were probably included in VB.NET to make the legions of disgruntled VB6 developers feel more comfortable when making the switch.

---

Well, OK, maybe not exactly. ;) I wasn't disparaging disgruntlement though. :)

As a long time VB6 programmer thats new to .NET how do you identify these non .Net functions? I would like to start this process correctly.

Quote:

---

Originally Posted by wes4dbt

As a long time VB6 programmer thats new to .NET how do you identify these non .Net functions? I would like to start this process correctly.

---

This has been discussed at length in the VB.NET forum. Some people suggest removing the Microsoft.VisualBasic namespace import from your project. That's not really needed though. All these Runtime functions are members of modules. If you can call a function without a qualifying type then it's a member of a module. If you call a member of a module and you haven't declared it yourself then it should be pretty obvious that it's a Runtime function.

For instance, the MessageBox.Show method is the Show method of the MessageBox class in the System.Windows.Forms namespace. The MsgBox function is the MsgBox function of the Interaction module in the Microsoft.VisualBasic namespace. No-one ever writes Interaction.MsgBox and no-one would. Because you can call the function without the qualifying type you know it's a member of a module. If you didn't declare it yourself you know it's a Runtime function.

Jmc you said

Quote:

---

I always recommend to people to avoid such functions unless they genuinely add value. MsgBox is a prime example of a function that I think should never be used. Many others who recommend not using them cite the fact that they may be deprecated in a future version as one of the reasons.

---

Is using MessageBox.Show equally offensive and if you don't use either what do you think is the recommended way of doing what a message box does?

MessageBox.Show is a native .net function.

MsgBox is native .NET. It was written in .NET and only executes .NET code when run. It just has syntax which is the same as the previous non-.NET function.

I don't understand why any of these would be 'bad'. If you are using Visual Basic .NET then why avoid the Visual Basic namespace which in part makes it VB?

Quote:

---

Originally Posted by EntityX

Jmc you said



Is using MessageBox.Show equally offensive and if you don't use either what do you think is the recommended way of doing what a message box does?

---

I do use MessageBox.Show. MsgBox does not do anything that MessageBox.Show doesn't. MsgBox has been implemented specifically so it behaves exactly like the MsgBox function from VB6, as have the rest of the Runtime functions. As has been said, they are all implemented in VB.NET, so they are not actually VB6 functions, but they exist specifically to mimic VB6 functions in syntax and behaviour. Some add value, others don't.

MsgBox is an example of one that doesn't. All MsgBox does is translate the parameters, call MessageBox.Show, then translate the return value. What's the point of that? Why ask Peter to ask Paul when you can just ask Paul yourself? The answer is that VB6 developers have always called the MsgBox function so they continue to do so since it's available. I can't see any purpose other than to provide a familiar interface to upgrading VB6 developers on a commonly used function. It serves no useful purpose in the context of an actual program.

That's not the case for all Runtime functions but MsgBox is certainly a poster-child for those opposed to their existence. Now, why are there those who are opposed to their existence? Why do we care? Basically, it's because VB.NET is not VB6 and we don't want it to feel like VB6. Pretty sad, but not as sad as needing a MsgBox function to feel comfortable with a new language. :) Does anybody want me to shut up now?

Quote:

---

Originally Posted by Edneeis

MsgBox is native .NET. It was written in .NET and only executes .NET code when run. It just has syntax which is the same as the previous non-.NET function.

I don't understand why any of these would be 'bad'. If you are using Visual Basic .NET then why avoid the Visual Basic namespace which in part makes it VB?

---

I want to chime in here, as I sort of agree with both of you..
These functions are a part of VB, and to say theyre bad bad bad, isn't fair.

However, users should be encouraged to learn and perform the true .NET way for one reason, it will allow them to be learning the c# way at the same time, if someone does use all the vb functions they will get a big shock when theyre all suddenly gone in c#, this is the reason they should be avoided.

I myself often use MsgBox() when debugging vb code, it's quicker to slap in isn't it? as I already understand it's a vb alias, there's no reason I shouldn't do so. and Hex() is certainly a nice shortcut.

If MS were to do anythig at all, i'd suggest the compiler simply give warnings on using legacy support functions (warnings that can be surpressed of course) rather than remove them, they do provide a good start for vb backgrounded people to use .net

This sounds like a fantastic idea to me:

Quote:

---

Originally Posted by Phill64

If MS were to do anythig at all, i'd suggest the compiler simply give warnings on using legacy support functions (warnings that can be surpressed of course) rather than remove them, they do provide a good start for vb backgrounded people to use .net

---

Having that would mean that people who are in the process of upgrading from Classic VB can import/write code without such a big learning curve, and convert the code (and themselves!) to the 'right way' as they get the time - which would of course be easier if the warnings contained a reference to the correct alternatives.

It would be even nicer if this was done using a collapsible group (called something like "Legacy functions to be upgraded"), so that the group can be ignored while correcting other issues.


A good alternative to this would be a separate downloadable tool (perhaps as an addin, but that wouldn't help Express Edition users) which reads the code files and gives those warnings/recommendations as appropriate.

Quote:

---

Originally Posted by si_the_geek

This sounds like a fantastic idea to me:Having that would mean that people who are in the process of upgrading from Classic VB can import/write code without such a big learning curve, and convert the code (and themselves!) to the 'right way' as they get the time - which would of course be easier if the warnings contained a reference to the correct alternatives.

It would be even nicer if this was done using a collapsible group (called something like "Legacy functions to be upgraded"), so that the group can be ignored while correcting other issues.


A good alternative to this would be a separate downloadable tool (perhaps as an addin, but that wouldn't help Express Edition users) which reads the code files and gives those warnings/recommendations as appropriate.

---

Brilliant.

When trying to help teach VB students in my school, I often try to explain to the teachers and the students that you shouldn't use the legacy functions, but no one ever believes me due to the fact that the book (vb .net book) only uses the legacy functions, and due to the fact that books are always right, why listen to logic? (I hate our ill-written school books)

However, the idea of warnings displayed when the user uses legacy functions is great!

Hi everyone,

Here's a good paper to read about this topic and contains recommendations on when to use the Microsoft.VisualBasic functions. Be careful making a blanket statement about always using the .NET framework classes directly. For instace, the conversion operators (CInt, CStr, CLng, etc.) are true operators that compile down to IL instructions while the System.Convert functions are still just functions. This means you'll get significantly worse performance by calling Convert.ToInt32 instead of using CInt(). Here's a post that explains this from Paul Vick.

-B

That's very useful to know, thanks Beth. :thumb:

These papers help understand the technical tradeoffs.

Seriously though, it's a good thing to use the vb runtime functions if that's what you're comfortable with (it's what I use in real apps) -- many people with a VB6 or VBA background should not have to relearn these concepts. It's not like the direct FX calls are best practices. There are so many other concepts we could insist on pushing other than this (proper exception handling, closing/disposing stateful objects, secure code).

Quote:

---

Originally Posted by PaulYuk_MS

Seriously though, it's a good thing to use the vb runtime functions if that's what you're comfortable with (it's what I use in real apps) ...

---

It's nice to hear that confirmation straight from the team!

I think we should still be open to trying out new .NEt stuff, to find out which ones really are better.
I mean just because MsgBox is comforable to the fingers, doesn't mean anyone should still keep using it, if it messes up execution. #3
I've seen it at least a couple of times too.

Quote:

---

Originally Posted by TTn

I mean just because MsgBox is comforable to the fingers, doesn't mean anyone should still keep using it, if it messes up execution. #3
I've seen it at least a couple of times too.

---

I really don't see how it could have. The only way that could be the case would be if the developer passed the wrong values to the function or misinterpreted the return value. I could be wrong but I very much doubt that there are any bugs in such a simple, well-used function.

I just don't see the point. I guess to me it seems that the inclusion of all those Runtime functions was a concession. It's a chunk of stuff that VB.NET didn't really need, included as an "incentive" for VB6 developers who felt they'd been "abandoned" because the language they were comfortable with had changed so much. Maybe I'm wrong. Does it really matter? Does anyone really care what I think anyway? :p

Quote:

---

Does anyone really care what I think anyway?

---

Not this time.

I guess variety is the spice of life.

Too much spice can give you indigestion. :D

I would find it hard to change to start using ms.vb but as Paul stated...

Quote:

---

many people with a VB6 or VBA background should not have to relearn these concepts.

---

This is probably the main reason why they created it for, to help us transition to .net. But IMO, a language shouldnt have to sell out to get users. If there are performance differences in favor of certain ms.vb functions then why could those imporvements be done with the .net equilivalent functions too?

Without learning you will not grow. I dont want to keep using CInt in .NET when it would seem logical to use a .NET function like DirectCast or such to get the same effect.

I'm going to be blunt:

Screw all this transition crap! It's a different language! Get used to it! We programmers are a tough species. If need be, we can adapt to using MessageBox.Show instead of using MsgBox. Hell, if you still want to be using MsgBox and all those VB6 written functions, then go back to VB6! Is it so hard to use MessageBox.Show instead of MsgBox? Intellisense does all the typing for you either way if you know how to use the IDE at all.

I can understand if you are using MsgBox instead of MessageBox.Show if you learned it from a crappy tutorial, teacher, or text, but if you know that MessageBox.Show exists and your small brain can't handle typing an extra 9 characters for an object oriented, well-written, undeprecated, updated function, maybe you shouldn't be programming or using anything above VB6 to begin with.

Blowing off steam is fun! :)

I know I'm in a religious debate here ;), but you haven't convinced me MessageBox.Show is a better practice. What is motivating us to push people off of it? Change is good if we can point to why it's really better, but change for change's sake is just a way to spend more time and money.

There are a lot of cases where we changed VB drastically to be modern, OO, and interopable with the .NET platform. E.g. arrays are 0-based, classes are classes, VB can call all .NET APIs, etc. This just doesn't meet the same bar IMHO.

OK.... by that same token, no one has convinced me that MsgBox is better either.

Looking back, here's what I see happened. People want VB to move forward. Of that there is no doubt, or we wouldn't be here. The problem is in the stigma that VB tends to carry. It's an unfortunate stigma, but one that I feel VB will carry around for as long as it keeps getting called VB. And that same stigma is carried over into the operators like CInt and some of the others. They are closely associated with VB6 and it's predecessors. Then we get told that the "proper" way is to do it the ".NET way" which includes dumping the paradigms of the "old" way and using "pure .NET" code. But I think some of that comes from a misunderstanding of what's going on under the hood of VB. It's one of the reasons why I am glad that we've had this opportunity to pick the minds of those who really do know what's going on. I've seen some myths dispelled this week, some confirmed, and learned some new things this week (thank you all for that).

For the record, I prefer MessageBox's parameter listing over MsgBox, for some reason the intellisense help I get is better. I do have a question about that though, and thinking about it, it is a bit relevant to the issue at hand. MessageBox is a member of the System.Windows.Forms namespace. I found myself last night having problems troubleshooting an issue in a Class Library project, which by it's nature does not have that namespace added as a reference. Forgetting this for about 5 minutes, I naturally had issues when a red squiggly showed up under messagebox. As I understand it MsgBox is actually housed in a module, correct? In the end, I simply set a reference in the project to the appropriate namespace and got MEssageBox working again. But this means when I go to take it out, I have a useless reference. If MsgBox is in fact housed in a module, I would have had access to it instantly, with out having to set a reference to S.W.F..... is this correct? If so, then this is one case that I see as a bonus for such things.

-tg

From the answers provided so far I'm assuming that the answer to this:

Quote:

---

Originally Posted by jmcilhinney

is there any likelihood that they will be dropped from the Framework at any point in the foreseeable future?

---

is "no".

By the way tg, the IDE has a feature that will remove unused references from a project in two button clicks. We should all really be doing that for every project when it's released anyway.