Re: order of KVO notification
Re: order of KVO notification
- Subject: Re: order of KVO notification
- From: Jeff Gilbert <email@hidden>
- Date: Tue, 27 Mar 2007 17:12:21 -0500
Thanks Mike.
Of course you are right about NSKeyValueObservingOptionNew. I have
been adding lots of KVO code for array changes and I was in the frame
of mind that NSKeyValueObservingOptionNew was just for reporting new
items added.
Jeff
On Mar 27, 2007, at 4:42 AM, Mike Abdullah wrote:
But if you are observing a non-array property this tells you the
new value that the property has changed to. Your code should be
something like:
- (void)observeValueForKeyPath:(NSString *)keyPath ofObject:(id)
object change:(NSDictionary *)change context:(void *)context
{
NSNumber *newPrice = [change objectForKey: NSKeyValueChangeNewKey];
}
You know this is the up-to-date price and there is no need to talk
to the cache.
Mike.
On 27 Mar 2007, at 01:38, Jeff Gilbert wrote:
Hi Mike,
I am not sure how I would use NSKeyValueObservingOptionNew in this
case. I am not looking for an item to be added, just for an
existing item to change an attribute. The "window" (see below for
a better explanation of my window) needs to access the cache to
obtain a piece of data that is otherwise expensive to generate.
My window is a 'data report' if you will. I have an object that
serves as the report generator, collecting a bunch of data from
the document and summarizing it into a form suitable for display
in an NSOutlineView. My NSWindowController subclass owns the
report generator and serves as the data source for the outline
view (feeding it the data provided by the report generator). So,
by window, I mean the window controller and report generator. I
should have been more specific.
My report generator is observing each individual Foo for its price
(along with other attributes). If the price for a particular Foo
changes then I need to update part of the report that depends on
both the price and the value obtained from the PriceValidator.
Unfortunately, the PriceValidator is not updated by the time the
report generator asks for the new data because the report
generator receives the KVO notification before the PriceValidator.
Thanks,
Jeff
On Mar 26, 2007, at 7:05 PM, Mike Abdullah wrote:
When registering the window for KVO, why not use
NSKeyValueObservingOptionNew? That way the window doesn't need
to talk to the cache in that circumstance.
Not really my business, but are you literally registering the
window itself for KVO? If so, that's not really that typical a
Cocoa design pattern. Surely you should at least have a custom
view instead?
Mike.
On 27 Mar 2007, at 00:20, Jeff Gilbert wrote:
Hi Everybody,
Is there a defined order that KVO notifications are posted to
observers?
For example, let's say I have a collection of objects (e.g. Foo)
with a price attribute. I have another object (PriceValidator)
that observes, via KVO, the price of all the Foos so that it can
maintain a cache of values related to the price. So, if one Foo
changes its price, PriceValidator will flush its cache. The
PriceValidator registers for KVO on Foo price when the document
is created.
I have a window that processes the Foo objects and uses KVO to
observe the price of the Foos. If a price changes, the window
retrieves a value from the PriceValidator. The window registers
for KVO on Foo price when the window is opened (via a user
command--this is not the default document window). This will
always happen after the PriceValidator has register for KVO.
Now, the problem is that the window will be notified of the
price change before the PriceValidator is notified of the price
change. So, when the window retrieves a value from the
PriceValidator it is an old value. I need the PriceValidator to
be notified first so that it can clear its cache. Then, when the
window retrieves the value from the PriceValidator it will
recompute the new value.
I was thinking that the PriceValidator would be notified first
since it was registered first. This does not seem to be the
case. Is it reasonable to expect this behavior? Is there any way
to cause this behavior? If not, can anyone recommend a useful
workaround for this?
thanks,
Jeff Gilbert
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
40mikeabdullah.net
This email sent to email@hidden
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden