Since you brought up ShellMessageBox...

The documentation discourages its use.  "Note  This function is available through Microsoft Windows XPÂ Service Pack 2 (SP2) and Windows Server 2003. It might be altered or unavailable in subsequent versions of Windows."

I assume that we should trust you instead of MSDN in this case?  If so, can you get that warning removed, and also clarify that the function uses TaskDialog when on Vista?

:-)

I like these dialogs so much more than the classic MessageBox ones. Huge improvement.

I'll get that warning removed; it's safe to use it. Thanks for the heads up!

Hi -

since you're looking at improvements to Message Box, why not

take a look at what I consider to be an enormous oversight: the

text is not selectable.

How many times have you gotten some long message with important

information like:

   Error fooing bar module in context har - terminating

   with event code 123-ABC-456-ABunchOfOtherInfo-XYZ.

   Please contact Dev Null at Lakov Support with this info.

and you have to write this all down by hand because someone might

ask for it and the developer may have slipped up and actually

written a useful error message?

I should be able to cut and paste text like this by default -

otherwise why even bother with any message more complex than

something like:

   Some error, somewhere - too lazy to help you more - bye.

per the industry standard?

It would be nice...

Thanks,

Devon McCormick

devon@acm.org

I think the new messagebox is very pretty but functionally I see no improvement. Images and fancy text styles may only distract users from the message. Also imagery in general is subjective to the viewer (is it nice looking or awful?). The vanilla MessageBox() has just text that cannot be misinterpreted or out of focus because it is plain. The only thing the new one has is a nicer presentation which does little more than waste memory/cpu.

DevCor - On Windows XP you can use Ctrl-C while a message box has focus and it copies the entire thing to the clipboard as text. Here is what is put on the clipboard if you bring up the run dialog and type test.exe.

---------------------------

text.exe

---------------------------

Windows cannot find 'text.exe'. Make sure you typed the name correctly, and then try again. To search for a file, click the Start button, and then click Search.

---------------------------

OK  

---------------------------

Chris

DevCor - you can actually use CTRL+C to copy the contents of the dialog!

alphisb0t - Thanks for the feedback. I feel that it is not only an improvement for developers, but also for users.

Task Dialog has a "Main Instruction" for the main message/question (e.g. Would you like to save this file?) which is a larger font & blue color.

It also has a "Content Area" which lets you supply additional context for the the message (e.g. If you don't save this file, you'll lose all of your information).

With this model, the user can read the main instruction and know what they are supposed to do. There are many times where developers but an entire paragraph of text in a dialog and it just makes it unreadable and confusing.

you're also forgetting you can add checkboxes, links, etc.. to it as well. this is a huge improvement over MessageBox()

I just want to second the idea that the text should be selectable and that copy/Ctrl-C should work on the selected text.  Ctrl-C for the entire box isn't really discoverable (I've been using Windows since version 1.0, and I just NOW hear about that?) while I've frequently been very frustrated at the inability to select text and copy it to another location.

Sadly, I seriously doubt that these APIs will be used very much outside of Microsoft.

Why? For many years to come, any viable commercial (and most corporate) applications will have to support Windows XP and 2000 as well as Vista.

If WPF is available for XP, why not APIs like these? Maybe I missed something, but it seems to me that Microsoft is shooting themselves in the foot by not providing some of the new common controls as redistributables or downloads for XP and 2000.

No no no!  MessageBox() should be marked DEPRECATED!  That is old skool.  We are now new school, which is ... the taskbar should be a messaging hub between the user and the system and the applications not just a container for running tasks.  Messages, for the most part from the system to the user should be transitory or informational.  

Now, if you HAVE to ask the user a question, please sit back and think for awhile and muse amongst yourselves, "We're microsoft and we have lots of development money and time ... I wonder if there's a way redesign this UI so that we can inhibit asking the question at all!  Or, perhaps we could have a default answer for most things and only the important stuff we will actually stop the action and make them answer."  

And if users WANT to answer one of your questions, give them Function keys or the mouse to answer and not the Enter key.  Or, how about  letting users Alt-Tab to the question and let THEM make the choice to make it modal!  But, above all, unless my harddrive is doing the click of death or there's a bad DIMM somewhere, the application should NEVER EVER lose context or be interrupted EVER by dialogs (unless the user has requested a dialog like the file picker, of course.)

Modal is disgustipating.  Modal is bad.  You put up a modal MessageBox while I'm typing just as I'm hitting the enter key ... NO NO NO, bad MSFT!  That's bad because I just OK'd some random app's question that bloody well should have been Cancelled!  Putting lipstick on the modal MessageBox pig like you are suggesting is very depressing.  Hanging up my system shutdown with 50 different dialogs when I want to just hit shutdown and walk away is damned infuriating.  NOTEPAD AND OFFICE SHOULD NOT HAVE MODAL DIALOGS!  God, I want to tell you how depressing this subject is.  I want to tell the entire shell team, to their faces (sorry for the yelling, bad breath, and spittle ahead of time), that anything modal depresses me and makes me heave just a leeetle bloop of bile up into my mouth when I think about it.

So after reading all that, when you say something just HAS to be modal, I would look at you critically and say that that's probably because of something else wrong at Microsoft that needs to be addressed - and once it is, you get rid of that modal and go have a pizza party because you've JUST REDUCED HUMAN SUFFERING IN THE WORLD.

What is less disgusting but still a little nausea inducing is the fact that SO MANY applications popup a notification doodad on the right top of the taskbar.  Firstly, that's hell in videogames that are fullscreen because it creates a clickable region and screws up the directX painting and the framerate.  Secondly, a lot of apps are so stupid (AIM) that they stack their own notifications and if many happen simultaneously, they just crawl up the right side of the screen in a motarded fashion - so automagical same-message-type grouping is needed.  Thirdly, separate apps typically don't know about one another and they stack their notifications on top of one another like naive little children without supervision.  These notifications should fold into the taskbar like any other non-modal message to the user.  

In summary you should code up:  API for sending notification messages with audio cues to the taskbar, auto taskbar resizing/reorg for these transitory messages (with sensitivity to mouse over and screwing up where the user is floating) so that it doesn't look annoying, same-message-type grouping, provide adequate training for users and get them used to the fact that the taskbar will, at a minimum, occupy significant (15%) screen real estate, design and supply default Windows styles according to the message type (IM vs MessageBox replacement vs new Outlook email).  Oh yeah, and at least get the API's into Vista, you can fix your apps in fixpacks but we need the API's now.  ;)

There, now I've said it, I know you'll have 1001 reasons to tell me I've been smoking too many narcotics and that what I'm saying is a load of hooey, so there's nothing I can say to save you.  I must say that I don't WANT to hate you shell people, but I will if you force me.  You can remain saddled to your annoying shell and my conscience will be clean because I said something about it.

Dave

Dave, love the passion, keep it coming.

IUserNotification does a tiny bit of what you want.

also tell AIM and other notificaiton based apps to use SHQueryUserNotificationState() to know when it is or is not appropirate to display their messages.

Nice article and addition to the API but why aren't new features like this part of the .NET framework so that backwards compatibility with XP and W2K are possible (with the framework installed of course)?  

I must also say that Davester's analysis of modality is right on (though I don't believe the solution is to do away with modal dialogs).  There must be a better solution (like detecting that a fair amount of typing has been going on or even a simply setting a global system timer when a key is pressed that basically prevents any modal dialogs from being dismissed before it expires.  This is just brainstorming out loud, but I think some real design time should be devoted to solving that problem.

johanatan, they can't be part of the .NET Framework, because that would require the apps to be managed code.  I think it would be overkill for a simple Notepad-like app to have to fire up the CLR in order to show a simple dialog box.

Regarding being interrupted by some random MessageBox when typing: in theory, since Windows 2000, this shouldn't be possible anymore.  Background apps' message boxes are not supposed to be able to interrupt your current task.  However I think a problem can still occur when you have multithreaded, multiwindowed apps like IE... a dialog from one IE window thread can take over another thread.

johanatan, they can't be part of the .NET Framework, because that would require the apps to be managed code.  I think it would be overkill for a simple Notepad-like app to have to fire up the CLR in order to show a simple dialog box.

Regarding being interrupted by some random MessageBox when typing: in theory, since Windows 2000, this shouldn't be possible anymore.  Background apps' message boxes are not supposed to be able to interrupt your current task.  However I think a problem can still occur when you have multithreaded, multiwindowed apps like IE... a dialog from one IE window thread can take over another thread.

PatriotB,

I think you're right, a MessageBox can't pop forward of another top level window.  But, isn't that almost a WORSE situation?  Now you've got a dialog blocking another app that's just sitting there way down in the window stack waiting because you can't see it, and you have to alt tab (or sometimes minimize everything else) just to dismiss the notification.  Information lost, time wasted.  :(  If the question went to the taskbar, you could always see the question and address it if you need to.  

chrisg,

I've heard about IUserNotification, isn't that what Mozilla Thunderbird uses?  The way it works is just as fugly as any other async notification popup thingy, if not one of the uglier ones in terms of animation.  SHQueryUserNotificationState() sounds like a good start for fixing the videogames and powerpoint getting overdrawn problem, but does it really solve the multi-notification stacking issue at the top right of the taskbar?

Back to my original point...  Part of the problem I see here is, Microsoft's not "conventionalizing" in Windows as much as they used to.  What I am getting at is something beyond standardization because there's a major, fundamental value-add provided.  Remember the good ol' days of MCI?  (Child windows)  Well, turns out that was a really good idea and it was a convention that any app could bank on.  Out the chute, you could Ctrl+Tab between child windows and you could Alt+Tab between top level windows.  Ctrl+Tab lost the battle at microsoft though and the taskbar took the hit with the *horrible* marketroid-inspired application window groups idea, but it doesn't change the fact that child windows was and is a really cool application convention provided by Windows that enabled great software and was practically a freebie.  

MessageBox's conventionalization could be similarly slicked up and give us more than just a way to express modality - it's replacement could build a two-way bridge between notifications and the apps they influence.  Consider Zone Alarm which (God forgive me for saying this) HAS to be somewhat modal (on the blocking socket thread.)  Anyhow, the client piece of that dumb app pops at random times when it needs to, and traps the 'a' and the 'd' keys for Accept and Deny.  If you were typing an email and were hitting 'a' (which has actually happened to me on many occasions), you could have just allowed the next big worm out of its cage, out to eat the world. Now, the MessageBox/IUserNotification replacement I'm thinking about talks to Windows and tells it what's going on, that a thread is blocked on some other process and it is asking a question for that process. Perhaps at that point, the window for the process with the blocked thread could pulsate/dim, or be tinted red, and the same color/animation could be expressed in the question notification on the taskbar, indicating the correlation.  'a' and 'd' are no longer trapped to express Accept and Deny, some other infrequently used keys are.

The other part of the problem is that everything still feels very wild west shootout in Windows.  Going modal at the drop of a hat and having apps that pop and steal focus constantly (Yahoo! Messenger, you suck) is still an acceptable practice.  Running native code is damned scary to me, and I know Microsoft was trying to go 100% VM and sandbox in Vista, and I hope they still would at some point in a fixpack.  Some bright bulb just needs to go through all of shell and platform API and mark things as "annoying" or "wild west shoot 'em up" and explain why so the brains can go to work on a rearchitecture.  The aforementioned problem with Zone Alarm going modal is that whatever conventions or API's Microsoft has put out for notifications did not suit them and they went with their own solution - which, not surprisingly, happened to be an ill-thought out crappy one!  I don't want to trust the market to fix this problem because the quality is going to be uneven:  MSFT has sported some of the best UI innovations in the past, and it just needs to cook up some new standards here.

Maybe all we need to satisfy 3rd parties is to create a new Window Type under the hood - one that apps paint to but that appears on behalf of and is resized/positioned on the taskbar by Explorer.  I know, I'm full of crazy ideas today...

There are more reasons to conventionalize MessageBox more, I think accessability is one of them.  There's all kinds of great stuff you could do there.  Speak the notifications in a different voice!  If Function keys were divvied out dynamically by windows to the selections on the dialog (see what I'm saying about 2-way bridge?), it would aid in the accessability as those could be spoken for the buttons.  I say we steal F9-F12 whenever the need arises for assigning to notification buttons.  That excites me, time for a cold shower.

Dave

It is about time for something like this.  How will/would this work with vbscript?  that is our primary coding tool for package installs.

PatriotB:

Well, they could at least be part of both the Framework and the API.  Only few apps can't afford the overhead (both size & performance) of the Framework.

ctrl+tab didn't lose at microsoft at all.  I use it all the time to switch between tabs in IE.  So it is still in use.  However, many programmes don't include that functionality at all.  My biggest complaint being Photoshop (unless i'm missing something).  It should be usable, not necissarily child-frames reliant.  Programmes should be coded to take advantage of this.

Adric,

You are exactly right!  Microsoft has softened Ctrl+Tab's meaning to go from the complex and awesome "cycle through the MCI window stack, and when user lets go of ctrl, also float the topmost window to the top of the order in the stack" to "go to the next/prev tabbed client window".  MCI windows now must have tabs to provide a proper user experience.  

Before, most recently used child windows were fewer Tab key taps away than least recently used.  Today, tabs always cycle in tab order and they do not rearrange when selected.  Plus, valuable screen real estate is wasted on stupid tab graphics.  And the tabs are darn distracting (to me) when they flip.

We've gone from a nice window stack that works like Alt+tab does for top level windows to cycling through tabs.  Functionality had to be lost because visually rearranging the tabs to match the stack order would blow people's minds.  THIS is why there are now application groups on the taskbar, because what were child document windows in some apps HAD to be promoted to top level because tabs were fugly to some app UI teams (like the Word XP guys.)  So now we pollute the taskbar and Alt+tab is now like flipping through a rolodex when a lot of documents are open.  As far as I can tell Ctrl+Tab does nothing in Word XP.  Bweegh, very sad...

But then again some Microsoft UI teams were suckers, they towed the new line about tabbed interfaces - and that's how we got from the simple and happy MCI Visual Studio 98 and got to the tabbed and pane'd C.F. called Visual Studio.Net.  

Marketroids, curse you for all your bad ideas and busybody focus groups!!  You had it right the first time with MCI.  At least concede to let us configure apps to work either way, tabbed or old school MCI, and make that acceptable from a UX guidelines perspective (with the default being tabbed interfaces.)

Dave

One of the blogs that I've found a lot of people seem to be linking to is the "Shell blog". One of the...

Maybe boxes shouldn't steal focus, but they do.  iTunes just did it to me.  Even Windows Firewall has done it - just as I was hitting ENTER, and I wound up agreeing to something, I don't know what.  Perfect timing.  My paranoia forced me to reimage my machine.

If you're worried about important messages, like Davester was saying, pop up a notification out of the tray.  If it's not mission critical, you can flash the Taskbar button or something to get my attention, but I'll get to it when I get to it.  Let me know you have something to say, but don't shout it in my face.

applejax,

Yep, asynchronous notifications is a real problem in windows.  No useful guidance there, it seems.  

I always thought flashing the window on the taskbar was clumsy and when you get multiple windows flashing simultaneously the taskbar becomes this evil christmas tree with lights all blinking at different times.  HTML blink at least had all the words blinking in time, sheesh ... I'd much prefer tinting the taskbar item a different color or perhaps overlaying some "NOTIFICATION WAITING" text in a different font over a whited-out taskbar item.

Flashing the taskbar is so Windows 95 and earlier anyhow, and it doesn't really say anything other than "LOOK AT ... HOW ANNOYING ... I AM! ..."

I want less bother, more cues, and more control.  Speed me up, make me more productive for goodness sakes.  Don't interrupt me, get out of my way, I shouldn't notice you or your code.  Don't ever force me to use the mouse, I should be playing windows like a friggin piano.  I want my hard-rockin' windows UI back.

Dave

About the  "Note  This function is available through Microsoft Windows XP Service Pack 2 (SP2) and Windows Server 2003. It might be altered or unavailable in subsequent versions of Windows.":

Remember this?

http://msdn2.microsoft.com/en-us/library/ms807073.aspx

As of the new VS2008 SDK, I can't get apps using ShellMessageBox to run under Windows XP!  There are conflicts between the .libs and .dlls as to where the function actually exists.  See my post on the forum on this site: http://shellrevealed.com/forums/thread/7613.aspx

Anyone know what's going on here?

MessageBox does the job, you can allways build something fancy with custom dialogs, like many apps do.

I dont think MessageBox will be deprecated in any near future.

Davester If you dont know how to use a computer and whant to shut down without the fuzz of messages why dont you just plug the power cable out ?

It's the developers who really need to make responsable use of MessageBoxes, just because we are used to click ok, next and continue doesn't mean we developers and users dont need them.

As a developer you can use hooks to enhance connmon dialogs and MessageBoxes, there are lots of tutorials out there, some people it's just lazy, i've seen cool things even on VB !

If you rather like to have a OS that let's you do things without warnings or popus why not to use Bourne Shell on SCO Unix ??.

Funny how VI let's you quit witout any "do you want to save this file ?"

You can delete the root partition with no warnings...