On 7 Mar 2011, at 13:45, Graham Cox wrote:
>> 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.
It seems that's the case, though I felt this was *exactly* what a sheet should
be for ("there is a problem that needs to be rectified before you can interact
further with this window" - it's just that in this case no harm will come from
choosing to ignore the problem by closing the window).
> 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.
Looks like I will probably end up doing
that..._______________________________________________
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
