• 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: Asynchronous call of Selector - is this code OK?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Asynchronous call of Selector - is this code OK?


  • Subject: Re: Asynchronous call of Selector - is this code OK?
  • From: email@hidden
  • Date: Fri, 1 Feb 2002 15:38:10 -0800

The problem is that it is massively inefficient, and is based on
polling.

No, it is based on (repeating) Timers.

Well, perhaps I am being excessively precise here, but... it is *based* on polling. The fundamental idea here is that you are polling someCondition periodically to watch until it changes. The fact that you're using repeating timers to get yourself time to poll someCondition is fairly irrelevant -- lots of different schemes for doing this could be concocted.
That said, what it is or isn't based on is completely irrelevant; I just couldn't let it go. :-> As for the actual issue at hand:

NSDocument:revertDocumentToSaved brings up a sheet ("Really want this?") and
then calls NSDocument:readFromFile _while_ this sheet is open. I have a
special case where I have to run some code _after_ the sheet is gone, but it
seems there is no method called after the sheet. I couldn't find any other
way than looking from time to time if my window has a sheet attached
anymore, and I have done this with the "delayed" function like in my sample
code where the "Condition" is "no sheet attached".

Ah yes, I remember you asking about this now. Well, it may call readFromFile while the sheet is open, but presumably it does this after the user has clicked OK -- I can't imagine it initiates the file read prior to user confirmation being received. I would guess that the sheet gets dismissed in the same run loop callout, probably just after readFromFile is called. So doing a performSelector:withObject:afterDelay: at the end of your readFromFile, with some suitably small delay like 0.1, should schedule you in for the right time without having to do this ugly polling business. Or not -- the ways of AppKit are mysterious. :-> But have you tried this?
I also note, in NSWindow.h, the notification and delegate message -(void)windowDidEndSheet:(NSNotification *)notification;, which looks like exactly what you want. However, I missed the beginning of this thread, so maybe this has already been discussed and is unsuitable for some reason...

Ben Haller
Stick Software


  • Follow-Ups:
    • Re: Asynchronous call of Selector - is this code OK?
      • From: Manfred Lippert <email@hidden>
  • Prev by Date: Re(4): optimizing compilers
  • Next by Date: Re: Re(4): optimizing compilers
  • Previous by thread: Re: Asynchronous call of Selector - is this code OK?
  • Next by thread: Re: Asynchronous call of Selector - is this code OK?
  • Index(es):
    • Date
    • Thread