On 07/03/2011, at 11:47 PM, Jonathan Taylor wrote: > Hi all, > > I have another UI type question where I am not sure how best to achieve what > I want. I have a (non-modal) window in which the user interacts with external > peripherals. Under certain circumstances (such as the peripheral not being > turned on) it is not possible to send commands to the device. I thought that > a window-modal sheet might be a neat way of representing that: > www.dur.ac.uk/j.m.taylor/sheet.png > > However, this sort of use of a sheet, window-modal in the sense that it > prevents interaction with that window, but non-showstopping in the sense that > it shouldn't prevent closing the parent window or quitting, seems to be hard. > I have found some mention of these issues in the archives and elsewhere, and > as far as I can tell: > - sheets are not really designed to work this way > - it is possible to allow quitting, for example manually closing the sheets > from within -terminate. > - it seems to be impossible to keep the close buttons enabled on the > underlying window (apparently "the underlying window is no longer first > responder"... although true, that in itself should not preclude the close > button from working unless I'm missing something). > > So - is there any way of keeping the close button operational, and/or can > anybody suggest a more appropriate way of achieving the sort of interface > effect I'm after here? I thought the sheet mechanism was a rather apt way of > doing what I want, but it is evidently not a use that has been foreseen in > the design...
I'd say you're trying to fit a round peg in a square hole, and attempting to subvert the sheet behaviour isn't going to be fruitful for you or your users. Instead why not open a hidden section in the window itself that displays the operational aspects of what's happening - or why even make it hidden? - so you have your input parameters in the upper section and the operational 'results' (perhaps including the progress bar, cancel button, error or progress message, and what-have-you) in the lower section. K.I.S.S. --Graham _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
