• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: modal windows (again)
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: modal windows (again)


  • Subject: Re: modal windows (again)
  • From: Allan Odgaard <email@hidden>
  • Date: Tue, 9 Mar 2004 18:27:21 +0100

On 9. Mar 2004, at 17:52, Devon E Bowen wrote:

Well, that sort of makes sense. But then you say:
This method is for the case where e.g. you'd need to do a lot of work
in the main thread but still wants your GUI to be responsive
So the purpose of runModalSession is to make sure a modal window does
not block. [...]

A modal window will block everything *but* its own window. So the user can use the window, but not any of the other windows of the application (if the modal "window" is instead attached to another window as a sheet, it will only block that window).

Also, there are probably parts of the GUI which needs to be responsive even when windows are blocked, like tooltips, menus and similar...

And runModalSession is exactly the method that is recommended
to be used in the NSGetAlertPanel() manual entry. So, in other words,
the manual clearly says that I can use NSGetAlertPanel() to make a modal panel that does not block the application.

Either it blocks the application or it is used as a sheet and only blocks a window. Do you want any of these two things?

What else do you think modal means?

Your code sample agrees:

session = [NSApp beginModalSessionForWindow:aWindow];
while(stuffToBeDone() && [NSApp runModalSession] == NSRunContinuesResponse)
doStuff();
[NSApp endModalSession:session];

The only difference between this and what I'm doing is that I call
runModalSession from inside a timer that goes off every tenth of a
second rather than in a tight while loop. [...]

And that is all the difference! In my code there is *no* main event loop running, so I make sure events (which are okay for the modal state) are processed.

In your example you *do* run the main event loop, and *additionally* runs a sort of local event loop, initiated by a timer.

There should only be one event loop running at a time, either your local (modal) event loop, or the main event loop.

[...] That runModalSession can *only* be called the way you have written it above. Although that seems extremely limiting. It means, I can't handle network events, etc, while a modal window is displayed.

Well, yes, sorta... modality is really something to avoid in most applications. It is only used for very short lived requesters such as "I need all of your attention, don't use any other windows before answering this question!".

However, if you handle network events e.g. via NSFileHandle, then the events will most likely be dispatched each time you make a call to runModalSession (this is why you have to repeatedly call it in your loop).

Though as hinted above, there are both panels which block the entire application, and those who are attached to a window -- for the latter part you generally do not setup a local event loop, but instead have a selector called when the user has dismissed the modal sheet.
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.


References: 
 >Re: modal windows (again) (From: Devon E Bowen <email@hidden>)

  • Prev by Date: Re: Please don't use "reply" to start threads.
  • Next by Date: Re: Convert Charatcers
  • Previous by thread: Re: modal windows (again)
  • Next by thread: Re: modal windows (again)
  • Index(es):
    • Date
    • Thread