I have overlaid a transparent window over my NSDocument's main window. My
intent is to draw textual notifications to it, such as "Processing...", "20
things selected...". The idea is partially experimental, etc. I thought it
would be neat to display a spinning icon in the a subclassed content vi
On Sun, Jan 31, 2010 at 4:19 PM, wrote:
> I have overlaid a transparent window over my NSDocument's main window. My
> intent is to draw textual notifications to it, such as "Processing...", "20
> things selected...". The idea is partially experimental, etc. I thought it
> would be neat to disp
As I understand then, all drawRect methods must be made from the main thread.
If I have a process running in the main thread, like an import thread which
mike take 5 seconds, then it impossible for me to have a secondary thread which
can update an NSView concurrently while the main thread is pro
What I want to do is this: display a spinning icon in a transparent overlay
window (I can do this no problem) while my program is saving, printing PDFs,
etc. These methods as typically defined in NSDocument do not have areas where
you can inject a call to update a progress bar. I'm thinking abou
On Jan 31, 2010, at 9:13 PM, Patrick Cusack wrote:
> What I want to do is this: display a spinning icon in a transparent overlay
> window (I can do this no problem) while my program is saving, printing PDFs,
> etc. These methods as typically defined in NSDocument do not have areas where
> you
You're going at it backwards. Do your UI work on the main thread, and
run your importer on the background thread. Or better yet use Grand
Central Dispatch.
--Kyle Sluder
On Jan 31, 2010, at 8:02 PM, Patrick Cusack
wrote:
As I understand then, all drawRect methods must be made from the
Ooh. So you need to perform this operation synchronously but still
pole the main thread (performing UI work is actually irrelevant; you
need to run the runloop to avoid the spinning beachball anyway).
So in your override of -writeToURL:…, spin off the background thread
like I suggested, the
Do you really really have to lock the UI? Are you sure?
--
Scott Ribe
scott_r...@killerbytes.com
http://www.killerbytes.com/
(303) 722-0567 voice
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator c
On Feb 1, 2010, at 7:20 AM, Kyle Sluder wrote:
> So in your override of -writeToURL:…, spin off the background thread like I
> suggested, then set up your UI, and then start running the runloop in a
> special modal mode until your background thread is done.
Nested runloops like this are usuall
On Feb 1, 2010, at 8:57 AM, Jens Alfke wrote:
>
> On Feb 1, 2010, at 7:20 AM, Kyle Sluder wrote:
>
>> So in your override of -writeToURL:…, spin off the background thread like I
>> suggested, then set up your UI, and then start running the runloop in a
>> special modal mode until your backgro
On Mon, Feb 1, 2010 at 10:20 AM, Kyle Sluder wrote:
> Ooh. So you need to perform this operation synchronously but still pole the
> main thread (performing UI work is actually irrelevant; you need to run the
> runloop to avoid the spinning beachball anyway).
>
> So in your override of -writeToURL:
So, let me clarify further:
Someone asked why a save operation would take a few seconds. I can answer that
I have an object model that is stored in ram and then serialized to disk. I
should have started the data model as a Coredata project, but decided not to
since my datasets would never be th
On Feb 1, 2010, at 12:11 PM, Patrick Cusack wrote:
As for NSRunLoop, let me see if I understand. I have created a new
Thread with [NSThread detachNewThreadSelector:toTarget:withObject:].
The selector is a do loop that periodically calls a custom NSView's
redisplay method that invokes [NSVi
13 matches
Mail list logo
