VB Runtime Functions

[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?

[Phill64]

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

[si_the_geek]

This sounds like a fantastic idea to me:

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.

[Fromethius]

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!