• 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: Blocking loops
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Blocking loops


  • Subject: Re: Blocking loops
  • From: Andreas Känner <email@hidden>
  • Date: Fri, 16 Jun 2006 16:34:08 +0200


Am 16.06.2006 um 16:20 schrieb Shawn Erickson:


On Jun 16, 2006, at 6:24 AM, email@hidden wrote:

I've got an application that does a fair bit of processing in a while loop...

<Code>
NSString* currentObj;
NSEnumerator* allObjects = [myArray objectEnumerator];
while (currentObj = [allObjects nextObject]) {
[progressBar setDoubleValue:((objIndex / [[fileController content] count]) *
100)];
[progressBar setNeedsDisplay:YES];
// Lots of processing here
} // while
</Code>


Unfortunately, the progress bar doesn't actually move (and the App is
unresponsive) until the loop completes. Is there a simple one line fix to this
(I'm thinking along the lines of Visual Basic's DoEvents() and Delphi's
Application.ProcessMessages()), or do I need to do some weird stuff involving
Notifications, and do away with (no pun intended) the loop?



Maybe that's not the best approach but the equivalent to DoEvents() is this:


[NSApp nextEventMatchingMask:NSAnyEventMask untilDate:[NSDate distantFuture] inMode:NSDefaultRunLoopMode dequeue:NO];

Andreas

Thanks for any help offered,

Consider throwing that work off to a secondary thread (NSThread) and in that loop (running in the secondary thread) use -[NSObject performSelectorOnMainThread:withObject:waitUntilDone:] to update your user interface (your progress bar).


Another option is to intermix you processing with a nested runloop, see NSRunLoop.

Finally you could break your work up and process it in steps using an NSTimer or a delayed selector call (once you process one object "schedule" the next one to be processed).

Personally I usually throw such stuff off to a secondary thread or possibly schedule a sub-unit of work on the main runloop (usually via a delayed selector call, -[NSObject performSelector:withObject:afterDelay:]).

An quick example of the later...
...
NSEnumerator* objectEnumerator = [myArray objectEnumerator];
[self processObjects:objectEnumerator];
...

- (void) processObjects:(NSEnumerator*)objectEnumerator
{
	id object = [objectEnumerator nextObject];
	if (object != nil) {
		... process object ...

... update UI ...

[self performSelector:@selector(processObjects:) withObject:objectEnumerator afterDelay:0.0];
}
}


-Shawn
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
40projectwizards.net


This email sent to email@hidden


_______________________________________________ Do not post admin requests to the list. They will be ignored. Cocoa-dev mailing list (email@hidden) Help/Unsubscribe/Update your Subscription: This email sent to email@hidden
  • Follow-Ups:
    • Re: Blocking loops
      • From: Bill Bumgarner <email@hidden>
References: 
 >Blocking loops (From: email@hidden)
 >Re: Blocking loops (From: Shawn Erickson <email@hidden>)

  • Prev by Date: Re: Blocking loops
  • Next by Date: Re: Blocking loops
  • Previous by thread: Re: Blocking loops
  • Next by thread: Re: Blocking loops
  • Index(es):
    • Date
    • Thread