Re: order of KVO notification
Re: order of KVO notification
- Subject: Re: order of KVO notification
- From: Mike Abdullah <email@hidden>
- Date: Tue, 27 Mar 2007 10:42:22 +0100
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