Re: How to catch modal window appearance?
On Mar 27, 2010, at 1:23 AM, Alexander Bokovikov wrote: On 27.03.2010, at 12:48, Ken Thomases wrote: I'm not really sure what you're asking for. A modal window being shown on screen is not something that happens spontaneously _to_ your application, it's something that your application does. So, whatever you want to do after the window is shown, just do it after the point in your code where you show it. I tried to achieve the next effect: some automatic process should be started on the modal window appearance on screen. A popup panel with progress indicator appears, etc. My idea was not to initiate such process from the calling code (where modal window is called from), but do it asynchronously, as soon as the modal window will appear on the screen. Of course, I've solved the problem by calling this process from the calling code just before [NSApp runModalForWindow:] call. But it is not pretty correct from the OOP philosophy point of view, at least as I understand it. Well, if you're using runModalForWindow: and relying on it to show the window, it goes away before the method returns, so there is no point in the code after show and before hide. But you can always do makeKeyAndOrderFront: explicitly: [myWindow makeKeyAndOrderFront:self]; // Stuff I need to do [NSApp runModalForWindow:myWindow]. ___ 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: How to catch modal window appearance?
On 30.03.2010, at 2:27, Lee Ann Rucker wrote: Well, if you're using runModalForWindow: and relying on it to show the window, it goes away before the method returns, so there is no point in the code after show and before hide. I understand it of course. I told about the window controller class code, not about the calling procedure code. But you can always do makeKeyAndOrderFront: explicitly: [myWindow makeKeyAndOrderFront:self]; // Stuff I need to do [NSApp runModalForWindow:myWindow]. Now I understand it. Initially I believed that there is an appropriate notification to do it. Thanks. ___ 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: How to catch modal window appearance?
On 26.03.2010, at 23:10, Fritz Anderson wrote: On 26 Mar 2010, at 11:12 AM, Alexander Bokovikov wrote: Is there any notification or NSWindow delegate method, called immediately after the modal window is shown on screen? It looks like windowDidExposed doesn't come to a modal window. Is there any solution? Just to check on the obvious points: * Have you set a delegate for the window, which would receive the windowDidExpose: message? * Have you named the method windowDidExpose: (without d, with :)? Yes, it's all done. That was just a typo in the email. I've copy/ pasted method declaration from the API Reference, so it's written correctly in the project. Nevertheless it is never called. I suppose that the problem is just the same as with other notifications - I need to do some actions to get them from a modal window message loop. But I have no idea of how to do it in this particular case. Thanks. ___ 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: How to catch modal window appearance?
On Mar 27, 2010, at 2:28 AM, Alexander Bokovikov wrote: On 26.03.2010, at 23:10, Fritz Anderson wrote: On 26 Mar 2010, at 11:12 AM, Alexander Bokovikov wrote: Is there any notification or NSWindow delegate method, called immediately after the modal window is shown on screen? It looks like windowDidExposed doesn't come to a modal window. Is there any solution? Just to check on the obvious points: * Have you set a delegate for the window, which would receive the windowDidExpose: message? * Have you named the method windowDidExpose: (without d, with :)? Yes, it's all done. That was just a typo in the email. I've copy/pasted method declaration from the API Reference, so it's written correctly in the project. Nevertheless it is never called. I suppose that the problem is just the same as with other notifications - I need to do some actions to get them from a modal window message loop. But I have no idea of how to do it in this particular case. No. I tried to make this point in the earlier thread -- the problem with the NSFileHandle notifications was not the issuing of the notifications. Those happen directly and synchronously as part of posting the notification. They don't involve the runloop or its modes at all. The problem in the earlier thread was the monitoring an external source of events/data. _That_ has to involve the runloop. NSWindowDidExposeNotification and the windowDidExpose: delegate method are only sent in very specific circumstances. As documented, it only applies to non-retained windows (backing type NSBackingStoreNonretained), which are almost never used. I'm not really sure what you're asking for. A modal window being shown on screen is not something that happens spontaneously _to_ your application, it's something that your application does. So, whatever you want to do after the window is shown, just do it after the point in your code where you show it. Regards, Ken ___ 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: How to catch modal window appearance?
On 27.03.2010, at 12:48, Ken Thomases wrote: I'm not really sure what you're asking for. A modal window being shown on screen is not something that happens spontaneously _to_ your application, it's something that your application does. So, whatever you want to do after the window is shown, just do it after the point in your code where you show it. I tried to achieve the next effect: some automatic process should be started on the modal window appearance on screen. A popup panel with progress indicator appears, etc. My idea was not to initiate such process from the calling code (where modal window is called from), but do it asynchronously, as soon as the modal window will appear on the screen. Of course, I've solved the problem by calling this process from the calling code just before [NSApp runModalForWindow:] call. But it is not pretty correct from the OOP philosophy point of view, at least as I understand it. What is over my mind is why Apple split main loop and modal loop. I see none of benefits but headaches.. There may be only one modal window at a time, isn't it? Thanks. ___ 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: How to catch modal window appearance?
On Mar 27, 2010, at 3:23 AM, Alexander Bokovikov wrote: On 27.03.2010, at 12:48, Ken Thomases wrote: I'm not really sure what you're asking for. A modal window being shown on screen is not something that happens spontaneously _to_ your application, it's something that your application does. So, whatever you want to do after the window is shown, just do it after the point in your code where you show it. I tried to achieve the next effect: some automatic process should be started on the modal window appearance on screen. A popup panel with progress indicator appears, etc. My idea was not to initiate such process from the calling code (where modal window is called from), but do it asynchronously, as soon as the modal window will appear on the screen. The window appearing on screen is not asynchronous; it's synchronous with your code which tells it to show. Of course, I've solved the problem by calling this process from the calling code just before [NSApp runModalForWindow:] call. You are allowed to show the window first (e.g. -makeKeyAndOrderFront:), initiate the process, and then call -runModalForWindow: if that will make you feel better about it, but I'm not sure I understand the distinction. But it is not pretty correct from the OOP philosophy point of view, at least as I understand it. I can't see how this is either correct or incorrect from the point of view of OOP philosophy. OOP involves encapsulation, separation of concerns, polymorphism, etc. Are you maybe thinking of the MVC design pattern? I would say that MVC suggests that the process be initiated by the controller, actually carried out by the model, and merely displayed in the GUI by the window. There's no real reason for it to be initiated in response to the appearance of the window. I would say it's the other way around: the window's appearance should be in response to the initiation of the process. What is over my mind is why Apple split main loop and modal loop. I see none of benefits but headaches.. There may be only one modal window at a time, isn't it? Well, first, you should consider whether a modal window is the best design of your GUI. I would say there's a mild recommendation that they be avoided in favor of document-modal sheets and the like. The splitting of the event loop, as you call it, is done because the results from a modal window are often desired synchronously in the code. That is, for example, you present an alert to get the user's response to some issue that's come up, and you want to know their choice before proceeding with the next step in your code. So, you invoke a synchronous method which doesn't return until the modal alert has the answer. Since you're not returning out to the main event loop, the synchronous method has to run a secondary event loop somewhere within it. Since the window is modal, there's nothing else that your application can or should be doing, in terms of the event loop, except processing the events for that window. So, it makes perfect sense that that should be in a separate event loop. I'm not sure why the use of two event loops makes much difference to you as a developer. Even if the modal window were handled by the main event loop, it would still require that the main event loop run in a different mode (either in the sense of runloop modes or using some other definition of mode or both). After all, it has to behave differently. That's the definition of a modal window -- events are handled differently. The framework would have to provide some mechanism by which the application switches the main event loop in and out of modal-ness. If you don't like the fact that -runModalForWindow: is synchronous -- it doesn't return to its caller until the modal loop is exited -- then you can use -runModalSession: instead, although that requires a different way of organizing the work being done during the modal session. I guess I'm in the opposite boat from you. I see some benefits and none of the headaches. What headaches flow from Cocoa's handling of modal windows? When developers relatively new to Cocoa have headaches, it's often because they are fighting the frameworks. They have a preconceived notion of how they want things to work and are trying to shoehorn Cocoa into fitting their preconception. When it doesn't fit well, they get frustrated. Give up the preconception and life gets much easier. Regards, Ken ___ 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: How to catch modal window appearance?
On 27.03.2010, at 1:59 PM, Ken Thomases wrote: I can't see how this is either correct or incorrect from the point of view of OOP philosophy. OOP involves encapsulation, separation of concerns, polymorphism, etc. separation of concerns is just the case. I would say it's the other way around: the window's appearance should be in response to the initiation of the process. My modal window's purpose is not just to show this initial process. It's a dialog, which does something more complicated, but this initial process should be completed to activate its subsequent functionality. Of course, we could show this progress before the modal window appearance. But I don't like it. Well, first, you should consider whether a modal window is the best design of your GUI. I would say there's a mild recommendation that they be avoided in favor of document-modal sheets and the like. It's not a document-based app. This dialogue does some thing which can't be shared in time with other functionality. It's just like Save File As... but more complex In MustDie all messages, addressed to the application, go through the window procedure of the modal window. Modal window is the key window, the main window, and whatever you do you do within it. Therefore I don't understand why notifications should be queued in the main loop while they can't be processed by the modal window messages loop. Thanks. ___ 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: How to catch modal window appearance?
On Mar 27, 2010, at 5:45 AM, Alexander Bokovikov wrote: On 27.03.2010, at 1:59 PM, Ken Thomases wrote: I can't see how this is either correct or incorrect from the point of view of OOP philosophy. OOP involves encapsulation, separation of concerns, polymorphism, etc. separation of concerns is just the case. Except the timing does not impact on separation of concerns. The controller, the C in MVC, should be responsible for the process, whether it is initiated before the window is show or after. I would say it's the other way around: the window's appearance should be in response to the initiation of the process. My modal window's purpose is not just to show this initial process. It's a dialog, which does something more complicated, but this initial process should be completed to activate its subsequent functionality. Of course, we could show this progress before the modal window appearance. But I don't like it. Huh? I didn't suggest showing the progress before the modal window appears. I just suggested initiating the process before it appears, but even that was just because you seem hung up on the ordering of initiating the process vs. the window's appearance. Well, first, you should consider whether a modal window is the best design of your GUI. I would say there's a mild recommendation that they be avoided in favor of document-modal sheets and the like. It's not a document-based app. Well, I said and the like. One doesn't need to have documents to have window-modal sheets. This dialogue does some thing which can't be shared in time with other functionality. It's just like Save File As... but more complex In MustDie all messages, addressed to the application, go through the window procedure of the modal window. As I thought, you have a preconception. You're apparently coming from Windows. In Cocoa, there's no such thing as window procedures. Modal window is the key window, the main window, and whatever you do you do within it. OK. For what it's worth, you could just have an ordinary window. So long as it's the only window presented by your app at that time, and so long as all menu items are either relevant to it or disabled, then you don't need to run it as a modal window if you don't want to. Therefore I don't understand why notifications should be queued in the main loop while they can't be processed by the modal window messages loop. You keep saying that. You don't understand that notifications are not in any way affected by the event loop or the runloop. When some code posts a notification, the notification center immediately iterates through the registered observers and invokes their selectors. It does this synchronously. It does this without using the runloop. Notifications are not normally queued. (One can use NSNotificationQueue to queue notifications, and that can interact with the runloop, but that's not typically how notifications from the framework are handled.) Some events and runloop sources are indeed not handled in certain runloop modes, and the modal event loop runs in a different mode than the main event loop. This is what makes the modal event loop modal. 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. 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. Regards, Ken ___ 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: How to catch modal window appearance?
Hi Alexander I tried to achieve the next effect: some automatic process should be started on the modal window appearance on screen. A popup panel with progress indicator appears, etc. My idea was not to initiate such process from the calling code (where modal window is called from), but do it asynchronously, as soon as the modal window will appear on the screen. I'm not sure if you realise how the MVC design pattern works. A window is just a view on data, it has no state or logic at all. Of course, I've solved the problem by calling this process from the calling code just before [NSApp runModalForWindow:] call. But it is not pretty correct from the OOP philosophy point of view, at least as I understand it. Every window is managed by a Controller and it is from this Controller that you can run any process you want, as well as creating and showing a window. There is nothing wrong with calling a process from a controller class; you can set to run in a secondary thread and display a progress indicator. What is over my mind is why Apple split main loop and modal loop. I see none of benefits but headaches.. There may be only one modal window at a time, isn't it? I think you are used to Windows programming. Cocoa modal sheets are modal to the owning form, not the whole app. Joanna -- Joanna Carter Carter Consulting ___ 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: How to catch modal window appearance?
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 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. 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... 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. But In the case of windowDidExpose: I don't see any way how to tell it to Cocoa that I'd like to get this notification. Thanks. ___ 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: How to catch modal window appearance?
On 27.03.2010, at 19:39, Joanna Carter wrote: Every window is managed by a Controller and it is from this Controller that you can run any process you want, as well as creating and showing a window. This is correct of course, and this was just what I tried to reach for. But I had to call this private code from the main AppController, rather than from a window controller of the modal window. Probably I was not too clear with my terms. I think you are used to Windows programming. Cocoa modal sheets are modal to the owning form, not the whole app. Modal sheet is not so suitable here. Modal sheet is located within the window which owns it. In my case popup window may be larger than parent window. Therefore I've chosen a real modal window. Thanks. ___ 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: How to catch modal window appearance?
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/2013-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 (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: How to catch modal window appearance?
On Mar 27, 2010, at 10:30 AM, Alexander Bokovikov wrote: I think you are used to Windows programming. Cocoa modal sheets are modal to the owning form, not the whole app. Modal sheet is not so suitable here. Modal sheet is located within the window which owns it. In my case popup window may be larger than parent window. Therefore I've chosen a real modal window. There may be reasons why a window-modal sheet is not suitable, but the relative sizes of the windows should not be one of them, in my opinion. A sheet is not within the the window which owns it; it's attached to it, and kind of on top of it. It is most definitely not analogous to Win32 child windows. Regards, Ken ___ 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: How to catch modal window appearance?
On 27.03.2010, at 20:36, Ken Thomases wrote: 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. OK, Finally I've come to some understanding. Finally, one extra question. When modal window runloop starts? Does it start after the window is shown on screen or before that? If it starts after window showing then I'd use performSelector:withObject:afterDelay: to be sure that my procedure will start to execute itself when window is already visible. Thank you! ___ 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: How to catch modal window appearance?
On Mar 27, 2010, at 11:01 AM, Alexander Bokovikov wrote: Finally, one extra question. When modal window runloop starts? Does it start after the window is shown on screen or before that? If it starts after window showing then I'd use performSelector:withObject:afterDelay: to be sure that my procedure will start to execute itself when window is already visible. Well, you can show the window yourself, explicitly, before invoking -runModalForWindow:, if you like. Then you can be sure the window is shown before the modal event loop starts. The exact details of -runModalForWindow: are, of course, an implementation detail that is private to the framework, but the documentation for that method says, [i]t displays the specified window, makes it key, starts the run loop, and processes events for that window. So, I assume it does those things in that order. However, I continue to be confused as to why you care. What's the difference if the procedure starts a fraction of a second before the window is visible or a fraction of a second after? Lastly, if you're going to try to use a -performSelector:... method to schedule something during that event loop, you're going to have to use one which allows you to specify the runloop modes in which it should fire (e.g. -performSelector:withObject:afterDelay:inModes:). Although, as I say, this technique is not necessary if all you're trying to do is show the window first. Thank you! You're welcome. Cheers, Ken ___ 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
How to catch modal window appearance?
Hi, All, Is there any notification or NSWindow delegate method, called immediately after the modal window is shown on screen? It looks like windowDidExposed doesn't come to a modal window. Is there any solution? Thanks. ___ 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: How to catch modal window appearance?
On 26 Mar 2010, at 11:12 AM, Alexander Bokovikov wrote: Is there any notification or NSWindow delegate method, called immediately after the modal window is shown on screen? It looks like windowDidExposed doesn't come to a modal window. Is there any solution? Just to check on the obvious points: * Have you set a delegate for the window, which would receive the windowDidExpose: message? * Have you named the method windowDidExpose: (without d, with :)? — F ___ 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
