Our documentation (and statements on the lists) claim a few things that I don't quite agree with. It says that you should be using the MessageDialog class instead of MsgBox, GetOpenFolderItem, GetSaveFolderItem and SelectFolder APIs. I am going to set the record straight on where I stand on the topic.
The MessageDialog class is great for a few cases. When you are developing for the Mac in the case of the FolderItem dialogs, or the dialog you are using has no standard UI to it for the platform you are running on in the case of MsgBox. That's it. Here's why (split into two parts):
FolderItem Dialogs:
There's no reason to use the MessageDialog version of these APIs if you are deploying to Windows. In fact, you should avoid using the MessageDialog version for fear of accidentally doing something wrong. You see, these dialogs let you do things to alter the look of the dialog. You can set the button captions, set the prompt text, etc. None of these things (with the exception of setting the window title) provide a standard UI on Windows. You're not meant to be able to change the button text, but we still hack it in there for you. So by using these dialogs, you can inadvertantly use non-standard UI on Windows.
You don't have this problem with the GetOpen/SaveFolderItem APIs since the option isn't there for you to customize the look and feel of the dialogs. Furthermore, these APIs are easier to use since they're one-liners. So the temptation to monkey with the UI in inappropriate ways is removed, and it's easier to use!
If you're developing for Windows, you should really consider not using the MessageDialog version of these APIs to ensure you always get the standard Windows look and feel. But the same is not true for the Mac, where all of the MessageDialog options are standard things you can set on the OS dialog box. If you are deploying to the Mac, then you may want to use the MessageDialog version since you will still be getting the standard UI for the dialog.
MsgBox vs MessageDialog:
You should be using MsgBox for much the same reasons as why you should use GetOpen/SaveFolderItem -- it provides the standard UI in a single line of code. The difference is -- the MsgBox class only needs to be used when you are trying to use that standard UI, otherwise MessageDialog will work just fine.
If you are going to be using any of the following concepts, then use MsgBox:
- Yes, No, Cancel
- Abort, Retry, Ignore
- Yes, No
- Abort, Retry
- OK, Cancel
You can use the extended form of the MsgBox class (the form that has a return value and takes optional parameters) to handle any of these cases -- and you will get a standard dialog box on Windows, instead of a custom one which could easily have the wrong look and feel.
Do I think these things are crucial to your success in deploying to Windows? Not really -- I don't think any of this is going to stop a user from using your product. But you should keep in mind that little things do add up. The more custom your application feels, the harder it is for a user to get used to it. And when users start getting frustrated when evaluating a product, they start moving on.
I have experienced problems with MsgBox on Windows. About 1/3 of the time, the window was either way too wide, or so narrow that the text was cut off. I have replaced all my MsgBox with MessageDialogs, and all my messages have displayed perfectly ever since.
That's kind of interesting... We fixed that problem recently, and the issue was happening because there were times when MsgBox was calling thru to MessageDialog under the hood and it was those calls that were causing the widening of the dialog (never seen the dialog get cut off though). So we fixed the MessageDialog class so that it didn't widen (it was a problem with getting string width of unicode text on Windows, IIRC) and then tightened up MsgBox so it was more strict about when it calls through to MessageDialog. So I am surprised that MessageDialog solved your problem, since it was most likely the cause of the problem in the first place.