Re: Progress window strategies?
Re: Progress window strategies?
- Subject: Re: Progress window strategies?
- From: "John R. Timmer" <email@hidden>
- Date: Mon, 08 May 2006 11:41:28 -0400
There seem to be a couple of issues here - one is how to determine
whether a dialog is needed at all, and the second is to get a process
that needs to happen on the main thread to retain user interaction.
For the first, the only thing that springs to mind is to check the
file size and make a guess based on that.
For the second, have you considered making an interface-free utility
program that you can launch from your own app? It's a very effective
way to have two main threads to work with, and it allows the app with
the interface to remain responsive to cancellations and such.
JT
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:
40bellatlantic.net
This email sent to email@hidden
____________________________________
Science writer, Ars Technica (among other things)
http://arstechnica.com/journals/science.ars
_______________________________________________
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