Non-showstopping sheets
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... Cheers Jonny___ 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
Re: Non-showstopping sheets
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
Re: Non-showstopping sheets
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
