Re: Modal-loop Event-handling question
Re: Modal-loop Event-handling question
- Subject: Re: Modal-loop Event-handling question
- From: Motti Shneor <email@hidden>
- Date: Tue, 01 May 2012 22:30:42 +0300
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 (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