Re: Manual reference counting and doubly-linked lists

Strong/retain for next, weak/assign for previous. On Nov 14, 2012, at 7:59 PM, William Squires wrote: > Let's say I have: > > @interface Thing : NSObject > > @property (nonatomic, ???) Thing *nextThing; > @property (nonatomic, ???) Thing *prevThing; > > @end > > and somewhere I keep a referen

Manual reference counting and doubly-linked lists

Let's say I have: @interface Thing : NSObject @property (nonatomic, ???) Thing *nextThing; @property (nonatomic, ???) Thing *prevThing; @end and somewhere I keep a reference to the 'head' of this doubly-linked list. What should ??? be, "retain", or "assign" in order to work properly? If I was

Re: Questions about CoreData and object graphs

Actually your guess is wrong. Core Data could handle this by turn the object to fault. Have a look at the method refreshObject:mergeChanges. Bob Cromwell On 2012-11-15, at 上午10:30, William Squires wrote: > 1) Can CoreData properly manage an object graph where the objects form a > circular

Questions about CoreData and object graphs

1) Can CoreData properly manage an object graph where the objects form a circular reference (i.e.) Entity Node int nodeType Node onTopOf // 1:1 relationship to another Node entity Node under // another 1:1 relationship End This would be a doubly-linked list in a circular queue so that you

Re: What makes a URL Handler be persistent?

On Nov 14, 2012, at 4:48 PM, Jerry Krinock wrote: > Why might my URL handler not be persistent? Off-the-wall guess? Probably because it's a handler on the helper and not your main app, so Launch Services isn't registering it when moving the main app around. Perhaps it only registers it when the

Re: Mysterious crash report

> Apparently this occurred when cancelling a document save, though it might > have nothing directly to do with that. At the time of the crash, NSToolbar > was doing something on the main thread... Since it was during document save and there's mention of XPC in the stack trace, I suspect the cras

What makes a URL Handler be persistent?

Normally, if a URL-handling app is not running, and user visits a URL with that app's scheme, Mac OS X launches the app. My app's URL handler only works when my app is running. That's not so bad, but I have one user reporting that it *never* works. I presume the issues are related and need to

Re: Mysterious crash report

On 15/11/2012, at 8:59 AM, Nick Zitzmann wrote: > Oh. I understand how that could happen with GC if the app tried to re-use a > finalized object, but the only resurrections I've seen happen under RR or ARC > were zombies… Sorry. Well, the crash is actually from libdispatch, so who knows what

Re: Mysterious crash report

On 15/11/2012, at 8:52 AM, Nick Zitzmann wrote: > > On Nov 14, 2012, at 2:26 PM, Graham Cox wrote: > >> We got this crash report associated with our app, which has us scratching >> our heads. It does not seem to be reproducible, but what does it mean 'API >> MISUSE'? > > Does your app use

Re: Mysterious crash report

On Nov 14, 2012, at 2:26 PM, Graham Cox wrote: > We got this crash report associated with our app, which has us scratching our > heads. It does not seem to be reproducible, but what does it mean 'API > MISUSE'? Does your app use RR, GC, or ARC memory management? Nick Zitzmann

Mysterious crash report

Hi all, We got this crash report associated with our app, which has us scratching our heads. It does not seem to be reproducible, but what does it mean 'API MISUSE'? What sort of code in our app might be kicking off this thread? Code Type: X86-64 (Native) Parent Process: launchd [164] Us

Notifications for changes to Finder Labels on Files

Hello List, I need to watch a file (Volume to be precise) for any changes the user makes to it's label. Currently I have a FSEventStream callback that watches the volume path and I react to kFSEventStreamEventFlagItemXattrMod since this gets modified on a Label change. Is there a more elegant