in Search

Do you Twitter? Follow us @CodeBetter

Grant Killian's Blog

No, this has nothing to do with beer -- but maybe it should?

CodingWorse (at least slightly) with MsgBox

My previous post pointed out the shortcomings of using Try-Catch blocks to handle situations that are not truly exceptional. In the same vein I offer this opinion on the VB.Net MsgBox() function -- note I say opinion because this time I don't have the astounding perf numbers to back me up. Here goes . . .

I was eating dinner tonight and showing a friend of mine a little VB.Net code. Yes, that's right -- a buddy stopped by and we were huddled around the laptop for a little nerdery and eggplant parmesan. This friend of mine does some Access development and I've been working on bringing him into the .Net fold. We got sidetracked for about 30 minutes on why I don't use MsgBox() and, instead, use MessageBox.Show(). While some will say it's only a matter of preference, I think it's more than that. MsgBox is the Visual Basic wrapper around the .Net Framework's MessageBox.Show method -- there is a tiny bit more overhead to MsgBox, but it's negligible especially when you consider you're halting your program to display a dialog box to the user! I can't really play the perf card here.

I think my two main issues with MsgBox are:

It reminds me of old VB6 and VBA days (like with Access); it carries a stigma of belonging to a bygone era. Comparing the IL for functions with MsgBox() and MessageBox.Show() is strikingly different: the MsgBox alternative calls into Microsoft.VisualBasic while MessageBox.Show() calls System.Windows.Forms. This might be a very very academic point, but I just get a warm and fuzzy feeling with System.Windows.Forms compared to Microsoft.VisualBasic.
I do a lot of C# programming and there's no MsgBox there! By learning the true .Net Framework I'm making my life easier -- it's more like I'm programming in only one language instead of VB.Net sometimes and C# at other times. I think Jeff Richter of Wintellect was the first to proclaim that all .Net developers are really programming in the same language. The Base Class Library is common to all .Net developers and the type systems can be coded the same (I could use System.Int32 instead of int or Integer -- and I did that for a while until I decided that was taking things too far). I can use the Show method of the MessageBox object in any .Net compliant language (even with Darrell's recent Python fixation!).

Call me a snob, but I know if I was reviewing code for a new hire and saw MsgBox() in their VB.Net code, I'd have a slightly -- just ever so slightly -- lesser opinion of the code. If it came down to two identical candidates, one MsgBoxer and one MessageBox.Shower, I'd hire the MessageBox.Shower for sure. MSDN even says MessageBox.Show is preferred.

I realize this is hardly a CodingWorse scenario on par with the previous try-catch transgression, but MsgBox just rubs me the wrong way.

Published Feb 02 2005, 08:36 PM by grant.killian

Comments

Eric Wise said:

Snob! =)

In all seriousness though besides the warm fuzzy feeling you get from calling System.Windows.Forms over Microsoft.VisualBasic I often wonder just how long we can expect Microsoft to continue support for the Microsoft.VisualBasic namespace.

In my very humble opinion your code is more "future complient" if you avoid the Micosoft.VisualBasic namespace altogether and use the Framework functionality.

Speaking of coding worse... one of the biggest sins I can think of as far as looking over code is when a "c#" developer references the microsoft.visualbasic namespace and starts using VB functions!

# February 2, 2005 8:44 PM

Scott Stewart said:

I have to admit, I started to go down this path and way of thinking myself. Way back in the old days when .Net 1 was in beta ;-), I started to teach myself C#. Mainly because I was sick and tiered of feeling like a second rate developer writing VB. Additionally, I had always been fond of c++ academically, but found myself using VB for work. So, I looked at this as my chance to kill a few birds with one stone. I would learn about .Net, and start using a real language professionally; something with curly brackets and semi colons ;-) Well after doing this for a while and feeling like I was getting pretty comfortable with C#, I got my first paying .Net job. It ended up being VB.Net.

When I first started using VB.net I really felt like it was just better to not go back to the “old” VB syntax. I found myself saying string.length instead of Len(string) because it was just more .Net like. MsgBox, didn't really come into play because it was a web form UI and not win. But the concept was the same.

After a while however, I started to change my approach towards this. Now I look at the situation this way: When I'm writing VB I'm writing VB. I'm going to follow good programming practices no matter what language I'm writing. But when I'm writing VB, I want it to look like and feel like VB. When I'm writing C#, it should look like C#. It should take advantage of any things that make C# different or better. I mean isn't that the purpose of having multiple high level language all compile to common language code? That each can provide different development productivity and coding styles, but all basically produce the same compiled runtime that can interoperate together?

As long as there is VB.Net, or VB.WhatsNext I am going to be comfortable using VB intrinsic functions. After all I'm writing in VB. The fact that it compiles to the same common language is a wonderful abstraction. But it’s an abstraction below, not above.

I would suggest that whenever you dabble in other languages you actually do take advantage of those languages intrinsic. Its what makes one language different (better) from another.

I'd hate to eventually be sitting at my desk writing IL.

Grant, as to your earlier post about Try/Catch and exception handling being used for exceptions only, is right on. I still come across code all the time where try catch is used almost like a conditional logic block; if this do this else do that - as if the exception is expected at this point in order for the proper logic to be determined.

# February 2, 2005 10:17 PM

Raymond Lewallen said:

I agree with you here Grant. I have the same feelings when I see CInt() rather than Convert.ToInt32, or Trim(myString) instead of myString.Trim. I try to avoid the VB namespace at all costs, and don't like to see it in other developers code either.

# February 3, 2005 6:19 AM

Paul said:

I agree with you in spirit, Grant. I think that it is good to go out of your way to try and use the framework wherever possible. I think it is especially important to be able to do so when you program in more than one language in .NET, and it certainly gives you an edge to talk about the pros and cons of one approach over the other.

That being said, I have it on good authority that the Microsoft VisualBasic compatibility library is not going away any time in the forseeable future. Microsoft is dedicated to continuing to support the legions of VB developers (who, on a side note, far outnumber C# developers) as much as possible. Part of this strategy is to include full language feature support that VB enthusiasts have enjoyed all along as well as making the upgrade path to .NET from VB6/VBA/etc. as easy as possible.

Is it language bigotry to think that in all cases you should use intrinsic framework calls over language-specific compatibility wrappers? Maybe to some degree -- but I think it is important to know that you are and to be able to talk intelligently about your decision. If we didn't have these compatibility libraries, then I'd imagine that the rich flavors of languages that run on .NET would begin to look pretty dull and indistinguishable between each other except for syntax.

# February 3, 2005 7:20 AM

Josh said:

Though I've had the same feeling (as a C# snob), I think I'd have to disagree. I was going to post something along the lines of Scott Stewart's comment, but he already did it for me.

If you are choosing to use VB, then I think you are completely within your rights to use everything the language has to offer.
Are you going to dock C# programmers for using the "using" statement (the one for IDisposable) because it isn't available in all languages?

The "correct, language agnostic" would be:
try
{
sr = new StreamReader(@"C:\myfile.txt");
contents = sr.ReadToEnd();
}
finally
{
if (sr != null) sr.Dispose()
}

Think about the upcoming "My" object/namespace/whateveritis in VB. From my understanding, it is mostly going to be a wrapper around other Framework calls. Are you going to completely discourage the usage of this lauded, major new feature?

Yes, I do get the same icky feeling when I see things like MsgBox being used, knowing that MessageBox exists. But I think that can really be attributed to the fact that I wouldn't use VB.NET, knowing that C# exists.

# February 3, 2005 8:32 AM

Grant said:

Whoa now folks, don't read so much into it. I don't intend to write IL instead of higher level code or anything. That's applying the specific (MsgBox) to the general (all VB.Net language distinctions). At least the comments have been civil and not degraded into a VB bash or anything silly.

For the record, Josh, the C# "using" statement has significant advantages over the alternatives . . . and that can't be said for MsgBox(). Use language features when they make sense; I maintain MsgBox() would only make sense if you're porting VB6 code over to VB.Net.

Paul Laudeman's remark about developers being fine if they use MsgBox, so long as they understand what's really going on, is more of what I'm getting at. And I, understanding what's going on, prefer MessageBox.Show() and would think people either
a) prefer MessageBox.Show()
or
b) don't care about something so trivial

# February 3, 2005 8:57 AM

Scott Stewart said:

Isn't funny how some of the simplest quick little blogs you write become great topics for discussion, and then other things that you consider personal manifest get no attention at all ;-)

I didn't mean to go overboard. I guess I was a little trigger-happy on this one. We recently had a contractor send an email to all the developers where I work suggesting that people not use VB intrinsic functions, but stick to common .Net ways of doing things. The statement was a generalization, and it suggested that we stop using "legacy" functions because they were less "object oriented". I'm a senior developer and a tech lead at the organization, and he sent the email without going through either myself or any of the other tech leads.

I hope that helps explain away a little of my perhaps trigger-happy overboard reaction. ;-)

By the way, keep up the good work. You guys blogging at CodeBetter.com seem to be off to a great start with some really good content!

# February 3, 2005 9:44 AM

Josh said:

Point taken on "using". I was hurting for an example, maybe that wasn't the best.

I guess the real shame is that MsgBox isn't just a wrapper around MessageBox.Show (though, maybe they are both just wrappers around the same Win32 call). And to know that, you need to have some knowledge of the internal implementation.

I'd LIKE to think that MsgBox is to MessageBox as Integer is to Int32. Then you are just choosing to use the native terms of your language. However, if they ARE different, their differences should be well documented so that developers can make informed decisions on which to use.

That MSDN article you mention says that MessageBox is preferred, but it doesn't say why, and then it goes on to say that the equivalent MsgBox code is acceptable.

Reading the documentation for MsgBox (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vblr7/html/vafctMsgBox.asp?frame=true), there is no mention that MessageBox.Show should be used in its place.

So we're all left to wonder, why IS MessageBox.Show better than MsgBox? And I have to chalk it up to my own C# snobbery.

I'll admit to one guilty VB.NET crutch: I like the file I/O functions Input & Write. The way they handle quoted strings and formatted dates,etc - going in and out - is magical. I know I should use StreamReaders/Writers and parse it myself, but...

# February 3, 2005 11:59 AM

Raymond Lewallen said:

I'll be the first to admit that my preference for using framework functions over vb namespace functions has nothing to do with anything other than I prefer it. Is there a performance difference? Yeah, when you get into 1 million plus calls or so, and then in most cases your talking about 100 ms at most (don't get into a discussion on that, I didn't really do the testing to support those numbers). So in a nutshell, there is really no big reason for using framework methods over vb namespace methods, in most cases, except that it becomes a personal preference. In hind-sight, my previous comment was useless in the fact that I didn't state why I preferred one way over the other, and I apologize for that. Truth be told, its just the way I like it, and nothing more.

# February 3, 2005 1:06 PM

Miroslav Gavrilov said:

I worked in VB6, then VB.NET but these days I'm having a big problem with it.. I open a new project (oogling all the other options like C#, C++ and such), and just sit and not do anything.. The code that I once loved (call me a loser :P), the VB syntax I was kinda fond of, it just gets me sick.. It's somehow icky and I don't want it.. So I passed to C# today.. And the first problem was how to make a property and how to make a Msgbox appear.. Which led me here.. And I have to admit, I like MessageBox.Show more.. Not only does it SOUND better but also makes the code more readable.. I think it's a beautiful idea to start bloging about such a small but important topic.. Thanks for your time :)

PS. Josh.. About the Input/Write.. I love them too ;)

# July 6, 2006 7:23 AM

Orb said:

This is pretty funny. The reason most of you dislike visualbasic namespace is because (I think) is because your not 'comfortable' with seeing old vb6 like code. Tough luck, it works, it's less typing a lot of the time and ppl that are used to doing something that works usually continue to use it.

I agree that using .net framework does make c# and vb.net almost the same language.

Don't begrudge ppl for using familiar language specific functions it makes the world a more interesting place.

Expand your mind, dudes.

# November 24, 2006 8:43 PM

Name (required)

Your URL (optional)

Comments (required)

Remember Me?