RE: [Q] What causes an NSArrayController to know that an entity was inserted via a different window?
RE: [Q] What causes an NSArrayController to know that an entity was inserted via a different window?
- Subject: RE: [Q] What causes an NSArrayController to know that an entity was inserted via a different window?
- From: "Jon C. Munson II" <email@hidden>
- Date: Wed, 25 Feb 2009 09:43:19 -0500
- Organization: JTA Enterprises LLC
After a clearer head/mind (yeah, verily, I was crapheaded yesterday), much Crow & Humble Pie for breakfast, much thinking, and much observation (especially after Jerry Krinock's post on thread re: Strange NSManagedObjectContextObjectsDidChangeNotification behavior), and in my case, I decided the best route for me was to use the -objectEnumerator found in the NSSet documentation coupled with the -isKindOfClass method to check for my class. While it would be nice to actually see if a certain attribute got updated (inserted/deleted is something that needs handling regardless), I can live with not knowing that piece of information.
Based on what I saw, read, and thought, this approach seems best to me. If there is a better idea, I'd love to read about it.
Thanks for dealing with me, sorry about the narrow-minded, fogged, clouded, idiocy of yesterday. I'll endeavor to do better.
Peace, Love, and Light,
/s/ Jon C. Munson II
> -----Original Message-----
> From: cocoa-dev-bounces+jmunson=email@hidden [mailto:cocoa-dev-
> bounces+jmunson=email@hidden] On Behalf Of Michael Ash
> Sent: Tuesday, February 24, 2009 9:12 PM
> To: cocoa-dev
> Subject: Re: [Q] What causes an NSArrayController to know that an entity
> was inserted via a different window?
>
> On Tue, Feb 24, 2009 at 3:37 PM, Jon C. Munson II <email@hidden> wrote:
> > In the method,
> > -(void)managedObjectContextUpdatedNotification:(NSNotification *)notif,
> the
> > notif contains userInfo. [userInfo valueForKey:] returns an NSSet.
> This
> > set has a -description, which returns a string formatted as a property
> list.
> > And there's where the documentation ends. In the debugger console,
> printing
> > out that description gives an "array dump," so I can see what is in the
> > description.
> >
> > My current solution is to call -rangeOfString on that description to
> look
> > for the data specific to the entity in which I'm interested (the name of
> the
> > entity in my case). That works pretty well. As the userInfo
> description
> > isn't too big (small entities), this works fine. However, I'm not
> convinced
> > this is the best way to get at that data.
>
> It's good that you're not convinced, because it's not the best way. In
> fact, I believe it could very well be the absolute worst way possible.
>
> What happens if the description of one of the other objects just
> happens to look like the description for yours? Disaster.
>
> You know that you have an NSSet. The documentation for NSSet will tell
> you how to inspect it to discover the presence or absence of an object
> within it, without going through such a crazy roundabout process.
>
> Mike
> _______________________________________________
>
> Cocoa-dev mailing list (email@hidden)
>
> Please 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
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please 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