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=his....@lists.apple.com [mailto:cocoa-dev- > bounces+jmunson=his....@lists.apple.com] 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 <jmun...@his.com> 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 (Cocoa-dev@lists.apple.com) > > 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: > http://lists.apple.com/mailman/options/cocoa-dev/jmunson%40his.com > > This email sent to jmun...@his.com _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
