On Fri, Aug 15, 2008 at 6:43 PM, Quincey Morris
<[EMAIL PROTECTED]> wrote:
> Lastly, before I shut up, in both Markus's question and the thread that Adam
> referred to, the idea was to trigger a KVO update when the property value
> was known to have *not* changed. In those circumstances, I still be
On Aug 15, 2008, at 15:05, Michael Ash wrote:
The problem then is that the empty will/did pair is used as a
*substitute* for the proper calls. It's sometimes too hard to wrap
every change in a will/did pair, so instead people put an empty
will/did call *after* the change. It is this which ends u
On Fri, Aug 15, 2008 at 2:02 PM, Quincey Morris
<[EMAIL PROTECTED]> wrote:
> On Aug 15, 2008, at 10:23, Adam R. Maxwell wrote:
>
>> Sending empty willChange/didChange messages is not a good idea:
>>
>> http://www.cocoabuilder.com/archive/message/cocoa/2008/5/18/207038
>
> Except that the idea of "n
On Aug 15, 2008, at 11:39 AM, Markus Spoettl wrote:
On Aug 15, 2008, at 10:23 AM, Adam R. Maxwell wrote:
Sending empty willChange/didChange messages is not a good idea:
http://www.cocoabuilder.com/archive/message/cocoa/2008/5/18/207038
That thread gives absolutely no explanation as to why thi
On Aug 15, 2008, at 11:02 AM, Quincey Morris wrote:
IAC, Marcus's alternative is to do this:
object.temperature = object.temperature;
I'm not sure how synthesized property setters are are constructed
exactly, but I believe that they check for an actual change in the
value and set
On Aug 15, 2008, at 10:23 AM, Adam R. Maxwell wrote:
Sending empty willChange/didChange messages is not a good idea:
http://www.cocoabuilder.com/archive/message/cocoa/2008/5/18/207038
That thread gives absolutely no explanation as to why this would be
harmful. Care to elaborate if you know
On Aug 15, 2008, at 10:23, Adam R. Maxwell wrote:
Sending empty willChange/didChange messages is not a good idea:
http://www.cocoabuilder.com/archive/message/cocoa/2008/5/18/207038
Except that the idea of "non-empty" willChange/didChange messages
doesn't cohere. The following is a perfectly
On Aug 15, 2008, at 12:23 PM, Adam R. Maxwell wrote:
Sending empty willChange/didChange messages is not a good idea:
http://www.cocoabuilder.com/archive/message/cocoa/2008/5/18/207038
Hmm, I've read that whole thread and still can't figure out why it's
not a good idea, other than mmalc says
On Friday, August 15, 2008, at 09:57AM, "Markus Spoettl" <[EMAIL PROTECTED]>
wrote:
>On Aug 15, 2008, at 6:40 AM, Negm-Awad Amin wrote:
>> [object willChangeValueForKeyPath:keyPath];
>> [object didChangeValueForKeyPath:keyPath];
>
>
>I tried that yesterday but due to a stupid mistake it didn't w
On Aug 15, 2008, at 6:40 AM, Negm-Awad Amin wrote:
[object willChangeValueForKeyPath:keyPath];
[object didChangeValueForKeyPath:keyPath];
I tried that yesterday but due to a stupid mistake it didn't work. I
does now and it's that's a good idea. it would eliminate the need of
changing thing
On Aug 14, 2008, at 11:37 PM, Quincey Morris wrote:
Can you not trigger the update by making the object property
(temperature) KVO-dependent on the preference setting? I don't mean
the object property's value, just the property itself. Either use
keyPathForValuesAffectingTemperature (or what
Hi,
Am Fr,15.08.2008 um 00:21 schrieb Markus Spoettl:
Hi List,
how can I make a view value which is bound to a property manually
re-read (or update) the value it displays?
The simplified setup is this: I have an object, that stores its
values (say a temperature) in Celcius. I also have
On Aug 14, 2008, at 20:10, Markus Spoettl wrote:
The problem is that I actually have a lot arrays of lots of objects
each with a number of different properties that can be displayed in
more than one way (all dependent on one preference settings).
Putting these through proxies/proxy arrays s
On Aug 14, 2008, at 9:47 PM, Caleb Strockbine wrote:
Why not use -setKeys:triggerChangeNotificationsForDependentKey:?
Make the key for your data dependent on the key for the preference,
so that anyone who's watching the data will get a notification when
the preference changes. This way, you
On Aug 14, 2008, at 8:36 PM, Markus Spoettl wrote:
When the user changes the preference, the view should update its value
so it uses the right units. There is no change to the underlying data,
so there's no change notification that would force the binding to
refresh the view.
So how can I manua
On Aug 14, 2008, at 8:20 PM, Ron Lue-Sang wrote:
Hmm yea, that's a bummer.
If I were building the views you're using, I'd publish another
binding in/from those views. Like "dataType" or
"ridiculouslyLongGermanStyleNameDescribingWhatTheBindingIsFor".
And then your views would really have two
On Aug 14, 2008, at 8:10 PM, Markus Spoettl wrote:
On Aug 14, 2008, at 5:07 PM, Ron Lue-Sang wrote:
Here's how I look at your situation.
Your view is bound to some property. It's job is to listen for KVO
notifications and redraw when it gets the KVO notification. That's
it. One input. Whe
On Aug 14, 2008, at 5:07 PM, Ron Lue-Sang wrote:
Here's how I look at your situation.
Your view is bound to some property. It's job is to listen for KVO
notifications and redraw when it gets the KVO notification. That's
it. One input. When there's a change on that one input, then redraw.
W
Here's how I look at your situation.
Your view is bound to some property. It's job is to listen for KVO
notifications and redraw when it gets the KVO notification. That's it.
One input. When there's a change on that one input, then redraw.
What you have is 2 inputs and only one notificatio
On Aug 14, 2008, at 3:28 PM, Kyle Sluder wrote:
On Thu, Aug 14, 2008 at 6:21 PM, Markus Spoettl
<[EMAIL PROTECTED]> wrote:
So how can I manually make the view update? It seems so simple but
I can't
figure out how to do this.
I can think of a couple of ways:
1) When your preference changes, p
On Thu, Aug 14, 2008 at 6:21 PM, Markus Spoettl
<[EMAIL PROTECTED]> wrote:
> So how can I manually make the view update? It seems so simple but I can't
> figure out how to do this.
I can think of a couple of ways:
1) When your preference changes, post a notification. The views
listen for that not
Hi List,
how can I make a view value which is bound to a property manually
re-read (or update) the value it displays?
The simplified setup is this: I have an object, that stores its values
(say a temperature) in Celcius. I also have an application preference
that lets the user switch be
22 matches
Mail list logo