Re: Non-showstopping sheets
Re: Non-showstopping sheets
- Subject: Re: Non-showstopping sheets
- From: Graham Cox <email@hidden>
- Date: Tue, 08 Mar 2011 00:45:51 +1100
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 (email@hidden)
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:
This email sent to email@hidden