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
