Thanks Jens, for your enlightening comments. On 30/04/2012, at 20:55, Jens Alfke wrote: > > On Apr 30, 2012, at 1:24 AM, Motti Shneor wrote: > >> In our client-server app we sometimes present modal sheets on our main >> window. Following server notifications we sometimes have to dismiss these >> sheets (user is expelled, or otherwise status-changed). > > To me, dismissing a sheet without any user intervention sounds like a > problematic UI design. It could be confusing if the user was about to do > something with the sheet (or was halfway through) when it disappeared. In the > worst case the user might be about to click an item in the sheet, and end up > clicking through to whatever control was underneath it in the main window. >
I agree this is not "nice" user experience, but ours is a "virtual meeting" system. Please compare: You talk to someone on the phone, then line is lost. Indeed some of your words will go down a dead line. This is the kind of situation I'm describing. In such situations, where the dialog (whether modal or modeless) has no meaning anymore, and whatever the user will do in it, makes no difference, because the context is gone (e.g. you want to send a little note to another participant. You open that dialog, and start typing.... Then the host expels you. Or the meeting is closed (scheduled) or... whatever. What good is to keep the dead UI, and thus mislead the user that he can complete the action he started? > I would suggest either making this UI modeless, or keeping the sheet up but > adding a banner or something to it alerting the user that she’s been logged > out. I'd rather replace the whole contents of the sheet with that banner you insinuate, but that's another discussion. Currently I need to overcome this crashing bug. > >> However, If we do this while the user holds one of the sheet buttons pressed >> --- within the mouse-tracking loop --- than endSheet happens, and then the >> mouseUp event reaches a released object (the sheet) which then crashes the >> application. > > Ouch. The best workaround to this that I can think of is to check the current > runloop mode, and if it’s NSEventTrackingRunloopMode give up without messing > with the sheet (or check again later.) > I can't just "give up" when I'm tracking the mouse. To avoid the crash, we tried to defer the "endSheet" via "performSelecor:@selector(closeAnyOpenSheet) afterDelay:0.0". This prevents the releasing of the dialog before the "mouseUp" event is received. However, when "mouseUp" event comes, the didEndSelector is called for the sheet-alert (before our deferred "endSheet" has a chance to happen), and then we face another problem --- we try to accomplish user command, in a dead context. No problem to patch a few "sheetDidEnd" methods, but we have dozens of them (all very different) and I would prefer general treatment for the problem. Do you know anything about the difference between "stopModal" and "abortModal" methods? Do you know which of these is being called by "endSheet" ? Is there a lower-level programmatic way to close the sheet and the modal session, giving up whatever event-loop is there? Thanks again@ Motti Shneor, Spectrum Reflections Ltd. _______________________________________________ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
