• 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: NSTextField refreshes are wacky.
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: NSTextField refreshes are wacky.


  • Subject: Re: NSTextField refreshes are wacky.
  • From: Kurt Revis <email@hidden>
  • Date: Tue, 12 Mar 2002 20:00:52 -0800

On Tuesday, March 12, 2002, at 07:09 PM, Jonathan Feinberg wrote:

To sum up: You need to use a different method to run your code in the main thread. I think some suggestions on how to do this were posted earlier, but let me know if you can't figure it out.

I may have missed that, unless you're referring to one fellow's suggestion to look into Distributed Objects. I'll go and absorb those docs now.

You can use DO to communicate across threads, and apparently it's the Apple-suggested way to do it. I think it's overly complicated and confusing, though--I remember trying to do it when I started learning Cocoa, and I just wasted a lot of time floundering. Maybe the documentation is better these days, though. There are lots of other ways to do it (each with its own pros and cons and variations).

One way is to have some shared state between threads, protected by NSLocks. For instance, in your case, you could have some variable(s) indicating how much progress has been made. You would do something like this:

in main thread:
create an NSLock
set state to initial value (0% complete)
start work thread
start periodic timer (NSTimer)

in work thread:
while (still more work to do) {
do a little work
lock the NSLock
update the state based on the work done
unlock the NSLock
}

in periodic timer in main thread:
lock the NSLock
copy the values in the state (as necessary)
unlock the NSLock
update the UI based on the copy of the state

This works well if you know progress will be steady, and that every time the timer fires there will be new progress to report. If your work thread takes longer than that, though, your periodic timer will be wasting a bunch of time polling when nothing has changed. In that case, things get more complicated. Essentially, from the work thread, you want to trigger a method to be called on an object sometime soon, but in the main thread. (In that method, you would update your UI.)

OmniFoundation (http://www.omnigroup.com/developer/sourcecode/) has a class for doing this called OFMessageQueue. From your work thread, you can call [object queueSelector:@selector(doSomething:) withObject:foo], and later on in the main thread, -[object doSomething:foo] will happen. The implementation is a bit confusing (since it is set up to do all sorts of advanced stuff, like allowing a queue to be processed by a pool of multiple work threads). However, if you concentrate on what the OFRunLoopQueueProcessor class does, you can probably get the basic idea.

There are undoubtedly other ways to do things, but that's what I use. You might take a look at the Cocoa-dev and MacOSX-dev archives for more info.

--
Kurt Revis
email@hidden
_______________________________________________
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.

  • Follow-Ups:
    • Re: NSTextField refreshes are wacky.
      • From: Jonathan Feinberg <email@hidden>
References: 
 >Re: NSTextField refreshes are wacky. (From: Jonathan Feinberg <email@hidden>)

  • Prev by Date: Re: NSTabView Problems
  • Next by Date: Re: preventWindowOrdering
  • Previous by thread: Re: NSTextField refreshes are wacky.
  • Next by thread: Re: NSTextField refreshes are wacky.
  • Index(es):
    • Date
    • Thread