Re: Progress window strategies?
Re: Progress window strategies?
- Subject: Re: Progress window strategies?
- From: Daniel Jalkut <email@hidden>
- Date: Wed, 10 May 2006 12:39:04 -0400
Hi Jim - can you take advantage of the documentation's claim that
begin/end only set up a modal session for running? It sounds like you
might be able to make those calls at well defined times before and
after the task is run.
Then in your progress handler, continue the strategy of only
"running" if the elapsed time has passed.
Does this work?
Daniel
On May 5, 2006, at 2:36 PM, Jim Correia wrote:
Some operations in my app, which happen on the main thread in a
blocking fashion, may take long enough that it warrants displaying
progress to the user. OTOH, if they are importing one tiny file, I
don't want to flash up a progress panel only to immediately tear it
down. (Doing this on a secondary thread isn't currently an option.
One of the operations is data migration which must be completed on
the main thread before the rest of the application is ready to use.
The other operations which would benefit from this use code that is
not thread safe, or hasn't been reviewed/modified with thread
safety in mind.)
I've got some code which looks like this.
@interface ProgressController
- (BOOL)run
@end
ProgressController *progressController = ...
[self doSomeWork: args progressController: progressController];
[self doSomeMoreWork: args progressController: progressController];
[progressController release];
The long operations periodically sends -run to the progress
controller. My first naive attempt at the implementation had it
start a modal session if enough time had elapsed since the
operation started. The modal session is ended when the window is
closed at the end of the operation.
The documentation says:
The beginModalSessionForWindow: method only sets up the modal
session. To actually run the session, use runModalSession:.
beginModalSessionForWindow: should be balanced by endModalSession:.
Make sure these two messages are sent within the same
exception-handling scope. That is, if you send
beginModalSessionForWindow: inside an NS_DURING construct, you must
send endModalSession: before NS_ENDHANDLER.
I obviously wasn't paying heed to those rules. -beginModalSession
could be sent in any call stack or exception handling context, and
the tear down has no way of knowing if an exception was raised
anywhere.
So the design is obviously bad (at least if I want to use modal
sessions.)
Does anyone have a practical solution to this problem?
Begin and end a modal session each trip through -run (if enough
time has elapsed)?
Abandon modal sessions entirely, and pull/dispatch my own events in
-run? (Which events, besides those destined for the modal window
must I dispatch?)
Thanks,
Jim
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
sweater.com
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