On Fri, Apr 4, 2008 at 12:08 AM, Mike <[EMAIL PROTECTED]> wrote:
> If that is the case then why does the progress bar get updated with the
> correct value every time when I insert the sleep( 1 ) call? Obviously it
> wouldn't be displaying the correct value if garbage was being sent to the
> selec
> If that is the case then why does the progress bar get updated with the
> correct value every time when I insert the sleep( 1 ) call?
Sounds rather like you might not be executing everything on the thread you
think you are.
--
Scott Ribe
[EMAIL PROTECTED]
http://www.killerbytes.com/
(303) 722-
On Apr 4, 2008, at 12:08 AM, Mike wrote:
If that is the case then why does the progress bar get updated with
the correct value every time when I insert the sleep( 1 ) call?
Obviously it wouldn't be displaying the correct value if garbage was
being sent to the selector.
I don't think it's
Ken Victor wrote:
At 1:08 PM -0700 3/31/08, [EMAIL PROTECTED] wrote:
Date: Mon, 31 Mar 2008 12:20:41 -0700
From: Mike <[EMAIL PROTECTED]>
Subject: Re: Main Thread UI and Detached Thread
To: Apple Cocoa List
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset=ISO-88
Well ok, let me rephrase that - I'm doing nothing *else* on my main
thread except executing the two update methods when the worker thread
asks the main thread to perform them.
j o a r wrote:
On Mar 31, 2008, at 12:25 PM, Mike wrote:
I am doing nothing in the main run loop when th worker threa
At 1:08 PM -0700 3/31/08, [EMAIL PROTECTED] wrote:
Date: Mon, 31 Mar 2008 12:20:41 -0700
From: Mike <[EMAIL PROTECTED]>
Subject: Re: Main Thread UI and Detached Thread
To: Apple Cocoa List
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
On Mar 31, 2008, at 12:25 PM, Mike wrote:
I am doing nothing in the main run loop when th worker thread fires.
The main thread is doing nothing but idling
This is not true, as you call to the main thread for display updates.
On Mar 31, 2008, at 12:28 PM, Mike wrote:
But my question is: w
On Mar 31, 2008, at 12:20 PM, Mike wrote:
I have two methods in the main thread that I call from the worker
using performSelector, etc. The method for updating the progress bar
for example looks like this:
- (void)setProgressBarValue:(double)value
{
if( progressBar )
{
Matt Mashyna wrote:
As long as we're top posting...
Why not update values for your worker thread and spawn another thread
that does the UI progress updates periodically ? Works nice for me. I
update the UI with whatever my controller object's state is at that
moment and then sleep for a littl
Hank Heijink (Mailinglists) wrote:
On Mar 31, 2008, at 2:06 PM, Mike wrote:
I suppose it's possible. The spawned thread does a lot of setup then
iterates some arrays of a bunch of objects in the filesystem that it
needs to delete. The idea is to update the progress bar one increment
with each
I have two methods in the main thread that I call from the worker using
performSelector, etc. The method for updating the progress bar for
example looks like this:
- (void)setProgressBarValue:(double)value
{
if( progressBar )
{
[ progressBar setDoubleValue:value
Yes, but in some cases the loop doesn't run for 10,000. It could run for
5 iterations or 100,000 depending on the # if files to delete.
There's no caveat in the docs on the use of
performSelectorOnMainThread:withObject:waitUntilDone:modes - the docs
make it sound that there are no restrictions
As long as we're top posting...
Why not update values for your worker thread and spawn another thread
that does the UI progress updates periodically ? Works nice for me. I
update the UI with whatever my controller object's state is at that
moment and then sleep for a little. I like this sch
On Mar 31, 2008, at 2:06 PM, Mike wrote:
I suppose it's possible. The spawned thread does a lot of setup then
iterates some arrays of a bunch of objects in the filesystem that it
needs to delete. The idea is to update the progress bar one
increment with each item being deleted. I'm using a
On Mar 31, 2008, at 11:02 AM, Mike wrote:
I'm not doing any work on the main thread while the spawned thread
runs. In fact, the main thread is just idling doing nothing. And the
behavior isn't really a responsiveness issue: the rest of the UI
still responds fine, but my indicators that I up
Are you calling performSelectorOnMainThread:withObject:waitUntilDone:modes on
every iteration of the tight loop? That seems like it could be terribly
expensive. What if you throttle it back to every X (ten, hundred, thousand,
etc) iterations? My speculation would be you're overwhelming your rece
I suppose it's possible. The spawned thread does a lot of setup then
iterates some arrays of a bunch of objects in the filesystem that it
needs to delete. The idea is to update the progress bar one increment
with each item being deleted. I'm using a MacBook 2.16 Ghz but I doubt
that the main th
I'm not doing any work on the main thread while the spawned thread runs.
In fact, the main thread is just idling doing nothing. And the behavior
isn't really a responsiveness issue: the rest of the UI still responds
fine, but my indicators that I update in the UI do *nothing* the entire
time th
Just checking the obvious here - is it possible that your worker
thread completes its work so fast that the main run loop hasn't
updated the screen once before it's done? Keep in mind that the main
thread has to display your window with the progress bar and the text
and (depending on your i
On Mar 30, 2008, at 11:55 AM, Mike wrote:
In my worker thread I do a tight processing loop and one of the
things I do in the loop is call two methods in the main thread to
update the display (a text message and progress bar) - via
performSelectorOnMainThread:withObject:waitUntilDone:modes.
I have all my UI running on my app's main thread. I have a worker thread
that I detach with detachNewThreadSelector:toTarget:withObject: (my
worker thread).
In my worker thread I do a tight processing loop and one of the things I
do in the loop is call two methods in the main thread to update
21 matches
Mail list logo
