> On 19 Oct 2016, at 15:08, Quincey Morris
> wrote:
>
> On Oct 19, 2016, at 00:49 , Gerriet M. Denkmann wrote:
>>
>> Before:
>>
>> TextField1 bound Value to:
>> Shared User Defaults Controller
>> Controller Key = values
>> Model Key Path = TextField1
>>
>> This worked fine.
>
On Oct 19, 2016, at 00:49 , Gerriet M. Denkmann wrote:
>
> Before:
>
> TextField1 bound Value to:
> Shared User Defaults Controller
> Controller Key = values
> Model Key Path = TextField1
>
> This worked fine.
Yeah, I didn’t realize you were binding to a NSUserDefaultsControl
Oo! I see! Here’s the main problem:
> On Oct 14, 2016, at 23:08 , Gerriet M. Denkmann wrote:
>
> My app (macOS 12) observes a value in NSUserDefaults.
Well, no, it doesn’t. It observes a value in a NSUserDefaultsController.values.
That’s a different kettle of wax.
First of all, any NS
> On 19 Oct 2016, at 13:01, Quincey Morris
> wrote:
>
>
> One way around this is to use a NSObjectController bound between the text
> field and the data model (user defaults in this case). NSObjectController
> implements the editor protocols, so this covers the case where the window
> close
> On 19 Oct 2016, at 08:01, Quincey Morris
> wrote:
>
> On Oct 18, 2016, at 22:33 , Gerriet M. Denkmann wrote:
>>
>> I have just done this (can send it to you if you are interested).
>
> I’d be interested at looking at it, if you can email it to me.
>
>> Bug4:changes not keep on qui
> On 19 Oct 2016, at 13:01, Quincey Morris
> wrote:
>
> On Oct 18, 2016, at 22:33 , Gerriet M. Denkmann wrote:
>>
>> I have just done this (can send it to you if you are interested).
>
> I’d be interested at looking at it, if you can email it to me.
Already sent by separate mail.
>
>> Bug4
On Oct 18, 2016, at 22:33 , Gerriet M. Denkmann wrote:
>
> I have just done this (can send it to you if you are interested).
I’d be interested at looking at it, if you can email it to me.
> Bug4: changes not keep on quit
> Check:change a TextField; do not use CR or leave the Tex
> On 19 Oct 2016, at 11:43,Jerome Krinock wrote:
>
>
>> On 2016 Oct 18, at 19:32, Gerriet M. Denkmann wrote:
>>
>>
>>> On 19 Oct 2016, at 02:00,Jerome Krinock :
>>>
On 2016 Oct 14, at 23:08, Gerriet M. Denkmann wrote:
>>>
Also: NSKeyValueObservingOptionNew or NSKeyValueObserving
> On 19 Oct 2016, at 09:55, Gary L. Wade wrote:
>
> I have a thought. Do you have a binding somewhere on a property in
> NSUserDefaults?
I just made a small test app: not document based, two TextFields bound to User
Defaults Controller at values.TextField1, resp. …2.
Both observed via addO
> On 2016 Oct 18, at 19:32, Gerriet M. Denkmann wrote:
>
>
>> On 19 Oct 2016, at 02:00,Jerome Krinock :
>>
>>> On 2016 Oct 14, at 23:08, Gerriet M. Denkmann wrote:
>>
>>> Also: NSKeyValueObservingOptionNew or NSKeyValueObservingOptionOld just
>>> return NSNull instead of old or new values.
I have a thought. Do you have a binding somewhere on a property in
NSUserDefaults? Maybe your document is getting synchronized to iCloud and/or
getting autosaved very often? These are things I’ve seen that can cause
uncharacteristically often updates.
--
Gary L. Wade
http://www.garywade.com/
> On 19 Oct 2016, at 02:00,Jerome Krinock :
>
>> On 2016 Oct 14, at 23:08, Gerriet M. Denkmann wrote:
>>
>> My app (macOS 12) observes a value in NSUserDefaults. Starting with macOS
>> 12 observeValueForKeyPath:… is called at the start of the program, although
>> nothing has changed yet. Wh
> On 15 Oct 2016, at 5:08 PM, Gerriet M. Denkmann wrote:
>
> Any workaround for these multiple (and unnecessary) calls?
Do they actually cause any problems? If not, just move on - there’s probably no
point worrying about it. If they do cause a problem, then that might indicate a
code smell o
> On 2016 Oct 14, at 23:08, Gerriet M. Denkmann wrote:
>
> My app (macOS 12) observes a value in NSUserDefaults. Starting with macOS 12
> observeValueForKeyPath:… is called at the start of the program, although
> nothing has changed yet. When the value actually changes, it is called twice.
My app (macOS 12) observes a value in NSUserDefaults.
Starting with macOS 12 observeValueForKeyPath:… is called at the start of the
program, although nothing has changed yet.
When the value actually changes, it is called twice.
Also: NSKeyValueObservingOptionNew or NSKeyValueObservingOptionOld j
15 matches
Mail list logo