jackiw@cs.swarthmore.edu (Nick Jackiw) (03/03/90)
Me again, same topic again, sorry. (You can drag a dead horse to water, but you can't make it sink...) Jim Reekes, in Zen & The Movable Modal Dialog, says that "The movable-modal dialog should NOT be used in the call to _ModalDialog." and lists two reasons: 1) Multifinder can't switch out from ModalDialog. 2) Your filter proc would have to handle updates, activate/deactivate, suspend/resume, drag, zoom etc. There's an obvious contradiction here: if Multifinder won't let you switch, then you're never going to get suspend/resumes, and if your dialog doesn't bring up any other dialogs on top of it, you won't get activate/deactivates either. Empirical testing shows that no, you can't switch from ModalDialog. (Which is strange: I thought you could, provided the windowProc wasn't of the [old] modal dialog variety. Whatever.) Finally, any one who has implemented a dialog which can possibly invoke and dismiss a second dialog has had to handle update events for arbitrary windows from within a filterProc before. No big deal. So the first premise is that (2) is no difficulty at all. There are times and reasons when the (existing) fact that _ModalDialog won't allow multifinder to switch have been put to good use. These reasons may not be quite as extensive as various folks (including most of the Apple reps in this group) tried to make them out last year here when justifying the behaviour of multifinder, but they do exist. SFGetFile is one classic example. So the second premise is that sometimes (not always), we *want* a dialog to keep major context switching from happening. Given these two premises, is there any a priori, implementation- or interface-specific reason we *can't* use WDEF#128 with _ModalDialog? [The zoombox bug was one; but does the fact that it's fixed indicate a commitment to continued _ModalDialog support?] Thanks. -Nick Jackiw k -- -----Nicholas Jackiw [jackiw@cs.swarthmore.edu|jackiw@swarthmr.bitnet]----- "Here is how I built this artificial mine. I snatched a female louse from the hair of humanity. I was seen to lie with her on three successive nights, and then I flung her into the pit." _Maldoror_, Canto II
mjohnson@Apple.COM (Mark B. Johnson) (03/09/90)
In article <ZJRF1QS@xavier.swarthmore.edu> jackiw@cs.swarthmore.edu (Nick Jackiw) writes: > > 1) Multifinder can't switch out from ModalDialog. > 2) Your filter proc would have to handle updates, activate/deactivate, > suspend/resume, drag, zoom etc. > >There's an obvious contradiction here: if Multifinder won't let you switch, >then you're never going to get suspend/resumes, and if your dialog doesn't >bring up any other dialogs on top of it, you won't get activate/deactivates >either. Empirical testing shows that no, you can't switch from ModalDialog. >(Which is strange: I thought you could, provided the windowProc wasn't >of the [old] modal dialog variety. Whatever.) Finally, any one who has >implemented a dialog which can possibly invoke and dismiss a second dialog >has had to handle update events for arbitrary windows from within a filterProc >before. No big deal. So the first premise is that (2) is no difficulty at >all. > >There are times and reasons when the (existing) fact that _ModalDialog won't >allow multifinder to switch have been put to good use. These reasons may >not be quite as extensive as various folks (including most of the Apple reps >in this group) tried to make them out last year here when justifying the >behaviour of multifinder, but they do exist. SFGetFile is one classic >example. So the second premise is that sometimes (not always), we *want* >a dialog to keep major context switching from happening. > >Given these two premises, is there any a priori, implementation- or >interface-specific reason we *can't* use WDEF#128 with _ModalDialog? >[The zoombox bug was one; but does the fact that it's fixed indicate >a commitment to continued _ModalDialog support?] > Nick, You did catch a contradiction. A modal dialog filter procedure cannot handle a MultiFinder event since MultiFinder doesn't send them to a dialog filter. The issue with MultiFinder events is with the use of modeless dialogs, which do not have a filter. Dismissing a secondary dialog does not necessitate the use of a filter procedure just to handle the update event. The call _DrawDialog (call by ModalDialog) will draw every part of a standard dialog. For non-standard parts, use the userItem procedure. If things get too complicated with userItems, then stop using dialogs per Technical Note 203. Using dialog filters are more difficult than the standard event loop. If you feel that dialog filters are easy, then event loops are even easier. You can simulate the effect of ModalDialog without the Dialog Manager. It is possible to prevent a major switch by making the dBoxProc window the active window. This appears to the user exactly as ModalDialog. Don't use ModalDialog with the movable-modal because it prevents switching. This is diametrically opposed to both the Human Interface Guidelines. It was specially designed for this purpose. The window should be simple enough to handle with the standard Window and Control Managers. You should ask yourself, "Why do I *need* ModalDialog?" I will demonstrate the code and interface for handling this window ASAP. Jim Reekes E.O., Macintosh Developer Technical Support -- Mark B. Johnson AppleLink: mjohnson Developer Technical Support domain: mjohnson@Apple.com Apple Computer, Inc. UUCP: {amdahl,decwrl,sun,unisoft}!apple!mjohnson "You gave your life to become the person you are right now. Was it worth it?" - Richard Bach, _One_