[Zimwy]

Hi,
Let's say I have the following:

Code:
NSProgressIndicator* progress;  (assume it's initialized and visible etc)
for (int i = 0; i < 5; ++i) {
     [progress setDoubleValue: (double) i];
}

I tried the following:

Code:
NSProgressIndicator* progress;  (assume it's initialized and visible etc)
for (int i = 0; i < 5; ++i) {
     [progress setDoubleValue: (double) i];
     sched_yield();
}

but that didn't work. I know that having an NSTimer constantly call back to update the progress indicator is a good thing to do, but the circumstances make that very ugly. Any ideas?

thanks,
gabe

[Chuckit]

I think NSRunLoop is what you're looking for.

[smeger]

When you update the value of a progress indicator, it's marked as needing display the next time through the runloop (with setNeedsDisplay: YES). Your code, however, never returns to the runloop, so it's not redrawn. You can manually redraw it each time through by calling [progress display].

A better bet is to stick the loop into a separate thread that messages the main loop with the progress bar value. The main loop then calls setDoubleValue, and the progress bar can update whenever the processor has enough cycles. Look into Distributed Objects, or use pthreads.

[Catfish_Man]

Originally Posted by smeger

When you update the value of a progress indicator, it's marked as needing display the next time through the runloop (with setNeedsDisplay: YES). Your code, however, never returns to the runloop, so it's not redrawn. You can manually redraw it each time through by calling [progress display].

A better bet is to stick the loop into a separate thread that messages the main loop with the progress bar value. The main loop then calls setDoubleValue, and the progress bar can update whenever the processor has enough cycles. Look into Distributed Objects, or use pthreads.

Or he could just use an NSTimer and save himself a lot of effort...

[Chuckit]

He already said that, for some reason, an NSTimer is really impractical for what he's doing. I'd think that indicates a problem with the program's structure, but y'know, whatever. His program.

[Zimwy]

Thanks for the responses. I was hoping to avoid pthreads as it's a bit overkill. As for some people who are unhappy with my design I can elaborate as to why it's uncomfortable to use an NSTimer (which is what I ended up doing anyway). Here is more or less the code before the NSTimer:

Code:
int totalCorrect[numTypes];
int tmpData[numTypes_];
memset(totalCorrect, 0, numTypes * sizeof(int));

int maxCorrect = 0;

for (int n = 0; n < trainingTypes_; ++n) {
   memset(tmpData, 0, numTypes * sizeof(int));
   [self computeNumCorrectInto: tmpData limitedTo: n];
   if (arraySum(tmpData) > maxCorrect)
      maxCorrect = arraySum(tmpData);
}

where arraySum just sums up the ints of the array and computeNumCorrectInto: fills in the array passed to it.

Now instead, since I have things split over different functions with NSTimers I've had to make a bunch of things member variables such as the n that was passed to computeNumCorrectInto and the totalCorrect array. Just seems messier.

gabe

[Wevah]

Couldn't you just pass those things in as the timer's userInfo object (e.g., in an NSDictionary)?

[Zimwy]

I don't think that would work. If I declared the array on the stack and then passed it into the user info of the timer wouldn't it already be popped off the stack by the time the timer goes off? Maybe not the first time, but it's a timer that repeats for about 5 mins, so it would definitely be gone soon. No?
I feel like allocating memory on the heap for this is just ridiculous but that's how it has to be.

gabe

[Wevah]

Yeah, it would be off the stack; that's why I suggested an NSDictionary. Actually, the userInfo object is declared to be an id, so it should be an Objective-C object, anyway (it's retained by the timer).

[Zimwy]

Ahh, I didn't know the userinfo got retained by the timer. That's very interesting. Thanks for the info!

gabe