Msgbox for C#

[Guest]

Hello, I'm a newbie to C#. Does it have a Msgbox function like VB6 i.e.
MsgBox "Hello World". What is the equivelant function? Does it have one?

Thanks for your time on this simple question

 

[Anne Nolan]

Yes, it's

MessageBox.Show("This is a message");

 

[Tom Porterfield]

Hello, I'm a newbie to C#. Does it have a Msgbox function like VB6 i.e.
MsgBox "Hello World". What is the equivelant function? Does it have one?

Thanks for your time on this simple question

System.Windows.Forms.MessageBox.Show(...)

 

[Michael C]

Hello, I'm a newbie to C#. Does it have a Msgbox function like VB6 i.e.
MsgBox "Hello World". What is the equivelant function? Does it have one?

Thanks for your time on this simple question

I got so sick of the long winded messagebox syntax in C# I wrote my own
function called MsgBox which called MessageBox.Show.

Michael

 

[Mark Broadbent]

??? what so you save typing all of 4 characters!

 

[Chad Z. Hower aka Kudzu]

I got so sick of the long winded messagebox syntax in C# I wrote my own
function called MsgBox which called MessageBox.Show.

Thats so odd coming from a VB developer. VB is muhc more long winded than C# in nearly every
aspect.


--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"

Develop ASP.NET applications easier and in less time:
http://www.atozed.com/IntraWeb/

 

[Michael C]

??? what so you save typing all of 4 characters!

You obviously can't count. You missed the ".Show" as well as all of those
parameters MessageBoxIcon.Information etc etc.

Michael

 

[Michael C]

Thats so odd coming from a VB developer.

That's one of the reasons I switched from VB.net to C# but for some reason
the MessageBox.Show stands out as being long winded. Most of the time I just
want to show a message with an ok button and the information icon. I use a
static class called GT for these sort of functions, eg:

MessageBox.Show("Text", "Caption", MessageBoxButtons.OK,
MessageBoxIcon.Information);
becomes
GT.MsgBox("Text")

if(MessageBox.Show("Save Changes", "Caption", MessageBoxButtons.YesNoCancel,
MessageBoxIcon.Question, MessageBoxDefaultButton.Button1) ==
DialogResult.Yes)
becomes
if(GT.MsgBoxSaveChanges() == DialogResult.Yes)

VB is muhc more long winded than C# in nearly every
aspect.

I had similar functions when using VB6 as well. Usually the caption is the
same for all messageboxes and it doesn't make sense to repeat it throughout
the app.

Michael

 

[Mark Broadbent]

Hahaha. Nice one!

So we have ...
Normal = MessageBox.Show(...)
= 15 char

Your = X + Y
where
X = chars needed to declare instance of your class OR chars of class -if
your method is static
Y = your function name
(oh and don't forget add a reference to your dll!)

I bet yours is bigger than the normal syntax. MessageBox.Show is overloaded
so those extra params are not necessary.

I know where you are coming from though, especially if you are using
particular default parameters for the same look and feel of your messagebox,
but reinventing the wheel JUST to save some typing is in this instance a
very bad idea. If you took this to it's logical conclusion you would be
eventually doing this for nearly everything in the framework.
I can think of a couple of reasons to do this kind of thing, but saving
typing aint one of them.

What I would do instead is create a simple VS macro OR use one of the
productivity editor add-ins to VS so that you could (at the press of a
couple of keys) insert the base code of your messagebox statement.

A couple of tools....
http://www.aivosto.com/codesmart/index.html
http://www.codesmithtools.com/
http://www.devexpress.com/Downloads/NET/CodeRush/

Br,

Mark.

 

[Michael C]

Hahaha. Nice one!

So we have ...
Normal = MessageBox.Show(...)
= 15 char

Your = X + Y
where
X = chars needed to declare instance of your class OR chars of class -if
your method is static
Y = your function name
(oh and don't forget add a reference to your dll!)

You're making a huge stretch here. For a start the class is already declared
with other common function in it (obviously you have such a class, right?).
The class is not in a dll and it is only declared once anyway. Have a look
at these couple of examples to see the big difference

MessageBox.Show("Text", "Caption", MessageBoxButtons.OK,
MessageBoxIcon.Information);
becomes
GT.MsgBox("Text")

if(MessageBox.Show("Save Changes?", "Caption",
MessageBoxButtons.YesNoCancel, MessageBoxIcon.Question,
MessageBoxDefaultButton.Button1) == DialogResult.Yes)
becomes
if(GT.MsgBoxSaveChanges() == DialogResult.Yes)

I bet yours is bigger than the normal syntax. MessageBox.Show is
overloaded so those extra params are not necessary.

Actually they are. You really need to have an icon on the messagebox so you
have to have at least the first 4 params.

I know where you are coming from though, especially if you are using
particular default parameters for the same look and feel of your
messagebox, but reinventing the wheel JUST to save some typing is in this
instance a very bad idea.

Total rubbish. How can this be a very bad idea? What possible side effects
could there be?

If you took this to it's logical conclusion you would be eventually doing
this for nearly everything in the framework.

Not really. If you think about it there are only a few places where you'd
use this sort of thing, the other one I use it for is adding params to a
command object.

I can think of a couple of reasons to do this kind of thing, but saving
typing aint one of them.

I don't see anything wrong with saving typing, although it also makes the
code more readable and reduces repeat code. If the caption of the MessageBox
is the same throughout the app why should I specify it in hundreds of
locations. (My app has 300 forms each of which would show at *least* one
messagebox).

What I would do instead is create a simple VS macro OR use one of the
productivity editor add-ins to VS so that you could (at the press of a
couple of keys) insert the base code of your messagebox statement.>

This sort of thing leads to lots of repeat code.

Michael

 

[Mark Broadbent]

So you're copying your (common) code function into every application. right?
What the hell happened to code reuse!

What happens if your class name (If statically declared) or instance name
(Otherwise) is greater than 2 characters! Starts to look a little less
efficient.

You say "my app has 300 forms etc etc". Nothing is wrong in having common
display in the app. In fact this would be a valid reason to do this kind of
thing -this is not what this thread was about ... "I got so sick of the long
winded messagebox syntax in C#". Also is VB syntax that much better cos it
uses MsgBox, even that needs same params to get the same desired display.

You also mention that "it makes the code more readable". Well to you it
might, but what happens if Joe Programmer decides to rewrite his own version
of a for loop (and use it throughout his code) cos he don't like the syntax
or Jane Developer does the same with a DataAdapter because she wants to use
the word Copy instead of Fill (and like Joe uses it thoroughout her
programs).
But wait. Thats not all they do. They have re-written all sorts of other
constructs too and used them extensively thoughout their code.

Now this is my personal opinion (and we both obviously disagree), *but* I
would just hate to have to pick up Joe's and Jane's code. Since they copy
the code of all their custom bits into each application, it has not only
caused additional Bloat but has caused inconsistancies in code since from
time to time they change the code of their custom methods.

Just a final thing, you say at the bottom "this leads to lots of repeat
code". Well I find this quite amusing I must admit. MessageBox has 12
overloads and I believe the maximum amount of parameters used in any one
overload is 6 (yes thats right SIX . That isn't causing repeat code).
My point is that if you have had to write some code to save your pinkies
from RSI for MessageBox then there is plenty of more deserving things in the
Framework that requires your alterations!

 

[Michael C]

So you're copying your (common) code function into every application.
right? What the hell happened to code reuse!

Certain functions I copy paste into each app because it's not worth having
them in a seperate dll. This is one of them.

What happens if your class name (If statically declared) or instance name
(Otherwise) is greater than 2 characters! Starts to look a little less
efficient.

It would have to be on *very* long class name.

You say "my app has 300 forms etc etc". Nothing is wrong in having common
display in the app. In fact this would be a valid reason to do this kind
of
thing -this is not what this thread was about ... "I got so sick of the
long winded messagebox syntax in C#".

That is not the only reason I use my MsgBox function, it's just the only
reason I stated at the start of this thread.

Also is VB syntax that much better cos it uses MsgBox, even that needs same
params to get the same desired display.

That's why I had similar functions in vb6.

You also mention that "it makes the code more readable". Well to you it
might, but what happens if Joe Programmer decides to rewrite his own
version of a for loop (and use it throughout his code) cos he don't like
the syntax or Jane Developer does the same with a DataAdapter because she
wants to use the word Copy instead of Fill (and like Joe uses it
thoroughout her programs).
But wait. Thats not all they do. They have re-written all sorts of other
constructs too and used them extensively thoughout their code.

You're using a common newsgroup technique where you take an idea to the
ridiculous extreme and use that in an attempt to show how rediculous the
original idea was. As long as this technique is used sensibly it will make
your code more readable. Tell me, can't you tell in an instant what this
code is doing:

SqlParameter idParam = GT.AppendParam(command, "@ID",
SqlDBType.UniqueIdentifier)

Now this is my personal opinion (and we both obviously disagree), *but* I
would just hate to have to pick up Joe's and Jane's code.

Of course, because they over did it.

Since they copy the code of all their custom bits into each application,
it has not only caused additional Bloat

That is just plain wrong. My MsgBox will save bytes for sure. Might not be
anything significant but you brought it up.

but has caused inconsistancies in code since from time to time they change
the code of their custom methods.

Again, if the idea is misused.

Just a final thing, you say at the bottom "this leads to lots of repeat
code". Well I find this quite amusing I must admit. MessageBox has 12
overloads and I believe the maximum amount of parameters used in any one
overload is 6 (yes thats right SIX . That isn't causing repeat code).

Yes it is. As an example, you specify the caption of the messagebox over and
over. Even if you use a constant you still specify that over and over and it
could be different in some places.

My point is that if you have had to write some code to save your pinkies
from RSI for MessageBox then there is plenty of more deserving things in
the Framework that requires your alterations!

Such as?

Michael

 

[Mark Broadbent]

Hi Michael, it's pointless me carrying this on since I think you are utterly
convinced of the usefulness of your function - and bottom line is that if
it works for you then all well and good. Also lets face it, the chances of
me having to maintain your code are slim to say the least (and it looks like
we are the only two who care) so there is no problem.

I never thought I'd spend this much time talking about a MessageBox -sorry I
mean MsgBox! ;-)

br,

Mark. (over and out.)

 

[Michael C]

Hi Michael, it's pointless me carrying this on since I think you are
utterly convinced of the usefulness of your function

Yeah, after using it for 7 years it's pretty unlikely you'd change my mind

- and bottom line is that if it works for you then all well and good.

This was one thing I decided on fairly early in my programming. I used to
wonder if it was worth making something fairly trivial into a function, at
one point I decided it was.

Also lets face it, the chances of me having to maintain your code are slim
to say the least (and it looks like we are the only two who care) so there
is no problem.

If you did the MsgBox function would be the least of your worries Lack
of documentation and sparse comments would make it pale a little

Michael