Re: How to catch modal window appearance?
Re: How to catch modal window appearance?
- Subject: Re: How to catch modal window appearance?
- From: Ken Thomases <email@hidden>
- Date: Sat, 27 Mar 2010 10:36:49 -0500
On Mar 27, 2010, at 10:20 AM, Alexander Bokovikov wrote:
> On 27.03.2010, at 16:57, Ken Thomases wrote:
>
>>> "separation of concerns" is just the case.
>>
>> Except the timing does not impact on separation of concerns.
>
> I'm not about timing. I'm just about code separation. Initialization is a part of dialogue, so its window controller is the right place, where this code should be located and where it should be called. But now it is called from the "main" AppController, where the dialogue is created and where runModalForWindow sits. Usually only initialization methods, using some data from the calling object, should be called from the calling object. At least we must do our best to minimize their number. In my case I have to call a pure "inner", I'd even say, "private" object method from outside of the object code. In my opinion it's not correct, though it's not so meaningful in this particular case. I'm just about a good style.
The app controller should just send a message to the window controller asking it to do the whole thing. Then, the window controller can create the window, initiate the process, and invoke -runModalForWindow:, in whichever order it prefers.
There's no need to expose the inner/private stuff to the app controller, if you think it doesn't belong there.
That's what I meant about your concern having nothing to do with OOP principles. You can design according to good OOP principles and the specifics of modal windows don't impact it one way or another. The two issues are orthogonal.
>> The controller, the C in MVC, should be responsible for the process, whether it is initiated before the window is show or after.
>
> Is "C" the window controller in my case? I believe, it is.
Well, the "C" means your controller layer, which may be implemented as one or several controller classes/objects, as you think best.
>
>> If the modal event loop processed all of the same events as the main event loop, then it wouldn't be modal -- the user would be able to do things outside of the modal window, like clicking on buttons in another window, or selecting menus not related to the modal window. So, I don't know how you expect that to work differently. But this has _nothing_ to do with notifications.
>
> Of course, I had in mind all events, related to the modal window. All other events should be ignored. But windowDidExpose: notification is related to the window, and it is called after I call runModalForWindow: Isn't it? Then why it doesn't reach my window controller, which is set as a window delegate? Where is the logic? It looks as a bug rather than as a feature...
You missed my earlier explanation. -windowDidExpose: is a delegate method which is triggered by the posting of the NSWindowDidExposeNotification. As documented, that notification is only posted in very specific circumstances -- specifically, only for non-retained windows which are almost never used -- so you're not going to see an invocation of -windowDidExpose: in any normal situation.
<http://developer.apple.com/mac/library/documentation/cocoa/reference/ApplicationKit/Classes/NSWindow_Class/Reference/Reference.html#//apple_ref/doc/uid/20000013-BCICGDDI>
<http://developer.apple.com/mac/library/documentation/cocoa/reference/ApplicationKit/Classes/NSWindow_Class/Reference/Reference.html#//apple_ref/doc/c_ref/NSBackingStoreNonretained>
This has nothing to do with runloops, event loops, modality, etc.
You've just latched onto -windowDidExpose: when it's not relevant to the situation at hand.
>> As we saw with NSFileHandle, where necessary it is usually quite easy to ask for an event or runloop source to operate in the modal runloop mode. It's just not a big problem. It seems like you're inventing aggravation for yourself.
>
> There was an explicit method how to call a notification, when we talked about NSFileHandle.
No. There was an explicit method to have NSFileHandle _monitor for the arrival of data_ on specific runloop modes. The monitoring of external events/data (which does involve runloops) is a completely separate issue from the posting and delivery of notifications (which does not involve runloops).
Regards,
Ken
_______________________________________________
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