> On Oct 7, 2016, at 6:51 PM, Quincey Morris
> wrote:
>
> Looking at the documentation a bit more carefully, though, I think it’s
> implicit. Each thread, it says, can have a “current” NSProgress object, but
> there can be parent-child relationships between NSProgress objects across
> thread
On Oct 8, 2016, at 00:42 , J.E. Schotsman wrote:
>
> So it’s still true that the root NSProgress object must update its KVO
> compliant properties on the main thread for bindings to work, I suppose.
Well, looking back at the code I actually wrote, I didn’t use this assumption,
so now I’m not s
> On 08 Oct 2016, at 03:51,Quincey Morris wrote:
>
> Looking at the documentation a bit more carefully, though, I think it’s
> implicit. Each thread, it says, can have a “current” NSProgress object, but
> there can be parent-child relationships between NSProgress objects across
> thread bounda
On Oct 7, 2016, at 02:28 , J.E. Schotsman wrote:
>
> It isn’t mentioned in the NSProgress Overview though.
You are correct about that, which makes me wonder how much of my understanding
I simply dreamed.
Looking at the documentation a bit more carefully, though, I think it’s
implicit. Each th
> On 06 Oct 2016, at 22:43, Quincey Morris
> wrote:
>
> Well, Apple has. NSProgress is a multi-purpose class, one of whose purposes
> is to provide a thread-safe way of trampolining the progress completion
> reports from a background worker thread to properties that may be safely
> accessed
> On 06 Oct 2016, at 20:46, Ken Thomases wrote:
>
> When you are using bindings, you must ensure that changes to the properties
> to which UI is bound happen only on the main thread. Depending on your
> design, you can often do something like:
>
> dispatch_async(dispatch_get_main_queue(), ^{
On Oct 06, 2016, at 12:05 PM, "J.E. Schotsman" wrote:
I have simple progress bar in a window that refuses to update normally.
I don't suppose it's as simple as progress.usesThreadedAnimation = YES;?
Sent from iCloud's ridiculous UI, so, sorry about the formatting
___
On Oct 6, 2016, at 13:26 , Jens Alfke wrote:
>
> Maybe someone’s come up with a generic proxy class that can be used to
> dispatch the notifications to the main thread?
Well, Apple has. NSProgress is a multi-purpose class, one of whose purposes is
to provide a thread-safe way of trampolining t
> On Oct 6, 2016, at 11:36 AM, J.E. Schotsman wrote:
>
> CoreAnimation: warning, deleted thread with uncommitted CATransaction; set
> CA_DEBUG_TRANSACTIONS=1 in environment to log backtraces.
Definitely looks like a threading problem — the view tried to use CA on the
background thread, but th
On Oct 6, 2016, at 1:36 PM, J.E. Schotsman wrote:
>
>
>> On 06 Oct 2016, at 19:43, Jens Alfke wrote:
>>
>> That means that KVO is going to call the view’s observeChange method on your
>> background thread, not on the main thread. Which I believe qualifies as
>> “updating the UI from a backgr
> On 06 Oct 2016, at 19:43, Jens Alfke wrote:
>
> That means that KVO is going to call the view’s observeChange method on your
> background thread, not on the main thread. Which I believe qualifies as
> “updating the UI from a background thread”, which is illegal. It may be that
> the view ha
> On Oct 6, 2016, at 10:04 AM, J.E. Schotsman wrote:
>
> Its doubleValue is bound to the progress value of my ProgressController
> class, so is “animating" and “indeterminate".
> ...
> The progress value and other values are changed on a background thread.
That means that KVO is going to call
Hello,
I have simple progress bar in a window that refuses to update normally.
Its doubleValue is bound to the progress value of my ProgressController class,
so is “animating" and “indeterminate".
If I print the values during a job everything is correct, but the progress bar
won’t update. It loo
13 matches
Mail list logo
