That was my idea, but I'm still getting the problem that if I display
a modal dialog then switch out of the application and back again it's
possible to select the lower window and bring it in front of the
dialog. It's possible that with a lot of faffing around I can cope
with all eventualities but to be honest I'd be concerned that the
next change to the OS would break it again. I'll try with sheets and
see if my clients will stomach them, if not I'll stick with Carbon
and CW.
This should be easy to fix. First off, if you can make a simple example of
this, file a bug on it.
According to various folks in the Cocoa Dev Central archives there are bugs on modal dialog behaviour since 10.1 that haven't been fixed, so this might be a case of 'don't hold your breath'. However I agree that grousing about something without filing a bug benefits nobody, so I'll file one.
You can also work around it in the mean time.
NSApplication has a modalWindow method that returns nil if nothing's modal.
If you've got an application delegate, use its
"applicationWillBecomeActive:" notification to send the modal window a
"makeKeyAndOrderFront:" message.
If you don't have an app delegate, have your window's delegate (typically
its controller) test the modalWindow value in its "windowDidBecomeKey:"
notification and if its not nil, tell the modal window to become key.
Either one should ensure that the modal window's on top when the app comes
to the front.
Thanks, this is the sort of thing I was thinking of doing.
Sticking with deprecated technology (CW) and designing your application
around users that dislike change is a better recipe for having problems due
to OS upgrades than going with Cocoa and filing bugs when necessary. I
assume you wouldn't be thinking Cocoa in the first place if you weren't
concerned about long-term maintenance and improvement.
However designing my application around people who are paying for it is the only option for me! I'm happy about proposing _improvements_ to the system, but to suggest that a feature must be removed as my new development environment doesn't support it isn't a good way to keep satisfied customers. In fact most of my return business is generated because the client can specify exactly how the interface behaves and the resulting application will match their business practices rather than dictate them. And from their point of view it still behaves like a 'real' Mac program.
I don't think it's a case of users disliking change in principle, but of having a change imposed on them for no apparent benefit. And, to repeat myself, they're the ones paying for it.
I am looking at Cocoa for the long-term, as you suggest. However not because it is vastly better (the Xcode IDE feels really old and clunky coming from CW, not quite like being back on MPW but close) but because Metrowerks have lost the plot/been done in by Apple (take your pick) and there's no other game in town.
Obj-C is nice though.
Besides, having used sheets, I personally have come to detest modal dialogs
(as for nested modals...). They visually suggest that you should be able to
copy information from inactive windows and paste it into the dialog, then
refuse to allow you to do so. The sheet at least lets you know where you
stand.
At the expense of being able to see the document contents, which gets on _my_ nerves at times. It would be nice to be able to choose between these ways of doing things to suit the particular requirement, rather than decide that one way is best and force everyone to use it.
Thanks for all the ideas and input.
Rev. Andy