Can you explain what you mean "permitting a modal dialog to be interrupted"? If Rev's modal dialogs are somehow not really modal that would of course I would be concerned too... I just don't understand the argument now. I just skimmed through bug #536, and still don't get it.
Alex,
Okay; fair question. By definition, a "modal" dialog box requires the user to dismiss it before -any- other activity can proceed within that application. To quote from the Rev docs: "The modal command pauses the running handler until the modal dialog box is dismissed."
The "ask" and "answer" commands are also modal. Again, to quote the docs: "Use the ask command when a handler needs to get information from the user before continuing." and "Use the answer command to get information or a confirmation from the user before continuing. The user must click one of the buttons to dismiss the dialog box."
There is no program running on the Mac (or Windows, for that matter) following the Human Interface Guidelines that would permit a modal dialog box to be interrupted unless it was highly specific and backtrackable; I'll suggest the "Print" dialog in Windows and Mac which has potentially many buttons to bring up little "sub-dialogs" about "options" or "printer setup" issues. However, in this case, the sub-dialogs return you to the "main" dialog and back out to the app in a "last in - last out" fashion. You would never be permitted to select "Quit" while in the middle of such a dialog (or nest of dialogs). Look at Excel, Word, PowerPoint, AppleWorks, Final Cut, Mail, Explorer, Communicator, Toast, Nero, Entourage, Outlook, you name it. It's just plain wrong and violates important rules about user expectations and leading the user down the path of least danger.
Consider this scenario:
You've created a word processing application. The user selects "Save" and you present a modal dialog to facilitate the saving. However, Rev permits the user to then select "Quit" and the application will quit without saving the document. Okay; so you add a little shutdownRequest handler to confirm the quit action. It would still occur while the Save dialog was present! Can you think of -any- application that would permit you to quit in the middle of such a dialog without first dismissing it? It's absurd.
In the case of Rev for OSX -and- Windows, it is possible to select the Quit command and have a shutDownRequest execute while you are in the middle of a modal dialog ("ask" or "answer" or even "open stack modal"). In other words, the "modal dialog" is not modal at all! If you are not forced to first dismiss the dialog, it's not modal. (Read that sentence again.) You can't have it both ways.
So I hope you really mean it when you say that you "would be concerned too" if the modal dialogs are "not really modal" because I have shown you that they are, indeed, not modal by the only standard that counts: Can you do something else that subverts the intent of the modal dialog while the modal dialog is present? If so, it's not modal. Can you nest modal dialogs? Of course; but you must dismiss them in a last in - last out method (as in the "Print" dialog discussed above). In Rev's case, there is a routine missing that screws up how an app is supposed to behave.
Now, someone wrote (and I don't remember who) that it's the developer's responsibility to disable the Quit menu item. Fair enough. Show me how that can be done in OSX and I'll have a workaround. But the ultimate responsibility to get this right rests with the Rev folks.
Regards, Barry
_______________________________________________ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
