Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsFree MagazinesWhite PapersSubmit Content
Discussion GroupsASP.NETWindows FormsLanguages.NET FrameworkVisual Studio.NET
Articles.NET FrameworkASP.NETToolsWindows Forms
.NET DirectoryOpen Source ProjectsUser GroupsWeb Resources
Related Topics
Visual Basic 6SQL ServerMS AccessOther DB ProductsMS Server ProductsMore Topics ...

.NET Forum / Windows Forms / WinForm General / December 2006

Tip: Looking for answers? Try searching our database.

MessageBox.Show(text) has blank caption - why?

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
wizofaus@hotmail.com - 29 Dec 2006 00:24 GMT
MessageBox.Show() provides an overload where you supply only the text.
I figured that, like MFC and similar frameworks, the caption would be
the application name, which is 99% of the time what you would want.
But no...the documentation even states that the caption is blank.  But
when would it ever be considered acceptable in a Windows application
that follows all the relevant GUI standards to have a blank title bar
(no caption)?  Even under the raw Win32 API for MessageBox, the caption
is the word "Error" if you don't supply one.  I can't think of any
reasonable justification for supplying this overload given its current
behaviour.
Scott M. - 29 Dec 2006 04:12 GMT
As opposed to your supposition that 99% of the time you would want the
application name as the messagebox's caption, I would say that 99% of the
time you wouldn't.  I believe that Microsoft agrees and has changed the .NET
MessageBox() class to reflect that.

> MessageBox.Show() provides an overload where you supply only the text.
> I figured that, like MFC and similar frameworks, the caption would be
[quoted text clipped - 6 lines]
> reasonable justification for supplying this overload given its current
> behaviour.
Herfried K. Wagner [MVP] - 29 Dec 2006 12:06 GMT
"Scott M." <s-mar@nospam.nospam> schrieb:
> As opposed to your supposition that 99% of the time you would want the
> application name as the messagebox's caption, I would say that 99% of the
> time you wouldn't.  I believe that Microsoft agrees and has changed the
> .NET MessageBox() class to reflect that.

I have to disagree.  A window's title bar carries important information,
leaving it blank is IMO a bad idea in general.  Personally I do not see any
reason for using a blank title bar text.

Signature

M S   Herfried K. Wagner
M V P  <URL:http://dotnet.mvps.org/>
V B   <URL:http://dotnet.mvps.org/dotnet/faqs/>

Scott M. - 29 Dec 2006 22:41 GMT
I didn't say that leaving it blank was the way to go.  What I said was that
99% of the time I want to put application specific data into the caption and
so, I wouldn't want the application name there.  IMHO, leaving it blank it
MS's way of leaving the door open for the developer to put whatever they
want there without forcing something (the generic application title) that
you probably don't want.

> "Scott M." <s-mar@nospam.nospam> schrieb:
>> As opposed to your supposition that 99% of the time you would want the
[quoted text clipped - 5 lines]
> leaving it blank is IMO a bad idea in general.  Personally I do not see
> any reason for using a blank title bar text.
Stephany Young - 29 Dec 2006 23:26 GMT
I get the impression that the 2 overloads of the MessageBox.Show method that
do not take a caption parameter have been provided so that we developers can
display a 'quick and dirty' message dialog when debugging without the need
to satisfy various other parameters of the other overloads of the method.
That is certainly the only situation where I use either of those 2
overloads.

Note also that with those 2 overloads, the dialog does not display an icon.
It would be very rare that I use MessageBox.Show, (except when
debugging/troubleshooting), without specifying an icon and therefore I must
supply a value for caption. (Certainly, I could supply an empty string to
get a blank title bar if I wanted that, but I can't think of a situation
where I would want to.)

>I didn't say that leaving it blank was the way to go.  What I said was that
>99% of the time I want to put application specific data into the caption
[quoted text clipped - 12 lines]
>> leaving it blank is IMO a bad idea in general.  Personally I do not see
>> any reason for using a blank title bar text.
wizofaus@hotmail.com - 30 Dec 2006 22:59 GMT
> I get the impression that the 2 overloads of the MessageBox.Show method that
> do not take a caption parameter have been provided so that we developers can
[quoted text clipped - 9 lines]
> get a blank title bar if I wanted that, but I can't think of a situation
> where I would want to.)

I agree - in fact I think it should use a default "error" icon too,
which is what MFC does.
It may be intended as a "quick and dirty" method, but I see no reason
why it can't assume some sensible defaults that will actually allow it
to be of real use in a genuine app (my application in this case is an
in-house license key generator, so I don't care too much, but a message
box with no title looks like some weird resource problem to me).
Stephany Young - 30 Dec 2006 23:09 GMT
But my whole point is that it is behaving 'sensibly'.

If I use either of those 2 overloads I don't want the framework
second-guessing me.

You may not care what your applications look like (even if they are only for
in-house use) but I sure as hell do!

>> I get the impression that the 2 overloads of the MessageBox.Show method
>> that
[quoted text clipped - 22 lines]
> in-house license key generator, so I don't care too much, but a message
> box with no title looks like some weird resource problem to me).

Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.