Thanks for all the feedback guys. I really need to rethink how I use KVO
throughout my application.
I've read Mike Ash's post, and see the issues there - I'm surprised there
aren't more places where the standard observations are tripping over each other.
Time for some refactoring...
Gideon
> Hi all,
>
> I have a KVO registration like this:
>
> [self addObserver:self forKeyPath:@"toOne.attribute" options:0 context:NULL];
>
> I establish this on -awakeFromInsert or -awakeFromFetch, and have the
> corresponding removeObserver called on -willTurnIntoFault.
>
> The problem is that wh
Ah. OK. keyPathsForValuesAffecting wouldn't be directly helpful there. But
KVO is easier to use with NS*Controller objects than directly with managed
objects. Can you bind your view to one of the standard controllers instead, and
have that controller track your managed object?
On 2010-08-09, at
On 2010-08-09, at 12:57 PM, Quincey Morris wrote:
>> On 10/08/2010, at 12:20 AM, Keary Suska wrote:
>>
>>>
>>> The trace shows that the destination has been invalidated before your
>>> object is faulted, and so the exception is raised when it tries to remove
>>> observation. Invalidated objec
On Aug 9, 2010, at 10:42, Kyle Sluder wrote:
> On Mon, Aug 9, 2010 at 10:23 AM, Gideon King wrote:
>> I don't quite get why I should be passing in something for the context when
>> setting up observing. I would have thought that that would be only for cases
>> where either:
>> a) you actually w
On Mon, Aug 9, 2010 at 10:23 AM, Gideon King wrote:
> I don't quite get why I should be passing in something for the context when
> setting up observing. I would have thought that that would be only for cases
> where either:
> a) you actually want to use some context data
> b) you have more than
OK, it's well after 3am now, so I'll leave more detailed analysis until after
some sleep.
The scenario is that of a simple Save As. As far as I am aware, I am not doing
anything unusual in the process. I do not forcibly invalidate objects. It's a
bit hard to track exactly what's happening, but
It's a graphical application, and when things change in the back end, I often
need to move things around on the screen, so need to invalidate the drawing
rect at the old location, perhaps remove some bezier paths, and then need to
set it to need display at the new location. I was just thinking t
On Aug 9, 2010, at 08:13, Gideon King wrote:
> Yes, Ben helped me a lot with sorting out the underlying issues, which turned
> out to be a number of misunderstandings about what various methods in the
> atomic store are supposed to do, what is required, etc etc. And at the time,
> we had got to
On 2010-08-09, at 11:13 AM, Gideon King wrote:
> Dave's idea of using + (NSSet*)keyPathsForValuesAffecting may help in
> some situations, but I don't think it's practical for all, especially where
> I'm using KVO for my front end to observe changes in the back end and react,
> where I sometime
Thanks Keary and Dave
Yes, Ben helped me a lot with sorting out the underlying issues, which turned
out to be a number of misunderstandings about what various methods in the
atomic store are supposed to do, what is required, etc etc. And at the time, we
had got to a point where we could save, s
On 2010-08-09, at 10:20 AM, Keary Suska wrote:
>
>> So I have two questions:
>>
>> 1. Is it the "right way" for me to be adding observation on the awake
>> methods and removing it on willTurnToFault?
>
> For cross-relationship KVO, generally yes.
Objects can turn into faults and then be refe
On Aug 9, 2010, at 4:51 AM, Gideon King wrote:
> Hi all,
>
> I have a KVO registration like this:
>
> [self addObserver:self forKeyPath:@"toOne.attribute" options:0 context:NULL];
>
> I establish this on -awakeFromInsert or -awakeFromFetch, and have the
> corresponding removeObserver called on
Why does the object need to be notified of changes? Is it to change its own
attributes in response? If so, you can define the class method
+ (NSSet*)keyPathsForValuesAffecting
There is no observer to set up or remove.
Dave
On 2010-08-09, at 8:42 AM, Gideon King wrote:
> The objective is for me
The objective is for me to be notified when "toOne.attribute" changes (either
by toOne changing or by the attribute changing).
Surely what I am doing is not getting the NSManagedObject to observe itself,
but rather the observer is self and the "observee" is the to one relationship
and it's attr
Gideon,
It looks like you have an NSManagedObject that is observing itself. If this is
in fact the case what is the objective? There may be a better way to accomplish
your goal if you let us know what it is.
Mike Swan
ETCP Certified Entertainment Electrician
http://www.michaelsswan.com
"As hum
16 matches
Mail list logo
