Re: Core Data : Undo Delete : Cannot fulfill a fault
On 2011 Sep 30, at 14:39, Quincey Morris wrote: > It would be interesting to know this: if you manually break the parent-child > relationships before actually deleting either the parent or the child, does > the order of the deletions matter? Invoking either -setParent:nil or -setChildren:nil on the object before invoking -[NSManagedObjectContext deleteObject:] fixes the problem. > Also, do you invoke 'processPendingChanges' yourself during the enumeration, > or do you just let it happen automatically? I do not processPendingChanges when deleting an object. Doing so after invoking -[NSManagedObjectContext deleteObject:] is another way to fix the problem. > Also, what's the delete rule for the child's "parent" relationship? Surely > not "Cascade"? Nullify. > If the delete rule for the parent's "children" relationship is "Cascade", > then you're (conceptually) asking for the child to be deleted twice (once > when the parent is explicitly deleted, once when the child is explicitly > deleted during the enumeration). I've no doubt this is safe enough in terms > of the deletions themselves, but I'm wondering if the way the sequence of > undo steps get recorded for this just isn't robust enough in the case where > the deleted objects are expunged (faulted out and removed from the persistent > store) before the undo happens. Yes, remember that inserting the objects and saving are necessary in the Steps to Reproduce. Pruning and unpruning trees is often hairy. You think you've thought through all of the possibilities, but then one day you find yourself sitting on a disconnected limb. ___ 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
Re: Receiving Crash Reports
On Sep 29, 2011, at 10:51 AM, Sean McBride wrote: > On Thu, 29 Sep 2011 09:12:31 -0600, koko said: > >> Thanks to all for suggestions. >> >> I was unaware that crash reports were routed to our iTunes Connect >> account . Question here, we distribute through the App Store as well >> other means. So, will all be routed or just those that came fe the App >> Store? >> >> I had been looking at UKCrashReporter and plcrashreporter and have not >> investigarted far enough to make a decision. > > I found FeedbackReporter to be the best since it can also report exceptions > in addition to just crashes. AppKit does this by default in Lion. It is available via a user default: NSApplicationShowExceptions (YES/NO) I recommend all developers turn it on. When an exception is thrown, it gives you a chance to crash the app and generate a crash report. corbin ___ 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
Re: Finder Integration
Hi Damon, On Sep 29, 2011, at 12:39 PM, Damon Allison wrote: > Hello, > > I am researching options for integrating with Finder. In particular, I would > like my application to provide file and directory icon overlays similar to > how Dropbox.app overlays green and blue images on top of file and folder > images. > > I noticed a few applications (svn utilities) that have used > `/Library/Contextual Menu Plugins` plugins to accomplish this. I've also seen > programs use SIMBL [1] plugins. Contextual Menu Plugins appears to have been > replaced by Automator Services, and SIMBL seems like an unsupported hack. > > Is there an 'official' way to integrate with the finder? No. You are welcome to log bugs asking for an API to do whatever you want. > If so, what is it? If not, how does dropbox accomplish their finder > integration? Via hacks, which are probably not compatible from release to release of OS X. corbin > > Either way, I would certainly appreciate any information / source code you > could provide. > > > Thanks, > Damon > > [1] SIMBL : > http://www.culater.net/software/SIMBL/SIMBL.php___ > > 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/corbind%40apple.com > > This email sent to corb...@apple.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
Re: Finder Integration
Please don't use SIMBL it causes grief for users and they don't know why. It messes with other applications. On Sep 30, 2011, at 3:21 AM, Matt Gough wrote: > Damon, > > Firstly there is no official way to do this, all the solutions you see in the > wild are hacks of one sort or another. > > Having said that, I had to implement what you are asking for (overlays on > icons) and did it via SIMBL. Unfortunately I can't share code or say too much > about what what is needed, but it would certainly help if you understood > method swizzling and found a way to dump all the Obj_c classes that the > Finder uses internally. > > Good luck > > Matt > > On 29 Sep 2011, at 20:39, Damon Allison wrote: > >> Hello, >> >> I am researching options for integrating with Finder. In particular, I would >> like my application to provide file and directory icon overlays similar to >> how Dropbox.app overlays green and blue images on top of file and folder >> images. >> >> I noticed a few applications (svn utilities) that have used >> `/Library/Contextual Menu Plugins` plugins to accomplish this. I've also >> seen programs use SIMBL [1] plugins. Contextual Menu Plugins appears to have >> been replaced by Automator Services, and SIMBL seems like an unsupported >> hack. >> >> Is there an 'official' way to integrate with the finder? If so, what is it? >> If not, how does dropbox accomplish their finder integration? >> >> Either way, I would certainly appreciate any information / source code you >> could provide. >> >> >> Thanks, >> Damon >> >> [1] SIMBL : >> http://www.culater.net/software/SIMBL/SIMBL.php___ >> > > ___ > > 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/jjoyce%40apple.com > > This email sent to jjo...@apple.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
Re: Core Data : Undo Delete : Cannot fulfill a fault
On Sep 30, 2011, at 13:22 , Jerry Krinock wrote: > The trick is the order in which they are deleted. If the child NewObject7 is > deleted before its parent NewObject6, Undo will succeed. If the parent is > deleted first, Undo will fail. In my app, the order is random due to > enumerating an NSSet. Yes, based on your last post I figured something like this, but I've been pondering where the "blame" lies. It would be interesting to know this: if you manually break the parent-child relationships before actually deleting either the parent or the child, does the order of the deletions matter? Presumably not. Also, do you invoke 'processPendingChanges' yourself during the enumeration, or do you just let it happen automatically? Also, what's the delete rule for the child's "parent" relationship? Surely not "Cascade"? If the delete rule for the parent's "children" relationship is "Cascade", then you're (conceptually) asking for the child to be deleted twice (once when the parent is explicitly deleted, once when the child is explicitly deleted during the enumeration). I've no doubt this is safe enough in terms of the deletions themselves, but I'm wondering if the way the sequence of undo steps get recorded for this just isn't robust enough in the case where the deleted objects are expunged (faulted out and removed from the persistent store) before the undo happens. ___ 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
Re: Question about SMJobBless
Ok, so the code to do the code sign check I am using is below. Furthermore, I
have my version of the SMJobBless app with these checks at:
http://ericgorr.net/cocoadev/SMJobBless.zip
The only remaining question is whether or not there is a better way or whether
the code-sign check is necessary?
if ( currentVersion == installedVersion )
{
SecRequirementRef requirement;
OSStatusstErr;
stErr = SecRequirementCreateWithString( CFSTR( "identifier
com.apple.bsd.SMJobBlessHelper and certificate leaf[subject.CN] = \"Joe
Developer\"" ), kSecCSDefaultFlags, &requirement );
if ( stErr == noErr )
{
SecStaticCodeRef staticCodeRef;
stErr = SecStaticCodeCreateWithPath( (CFURLRef)installedPathURL,
kSecCSDefaultFlags, &staticCodeRef );
if ( stErr == noErr )
{
stErr = SecStaticCodeCheckValidity( staticCodeRef,
kSecCSDefaultFlags, requirement );
needToInstall = NO;
}
}
}
On Sep 30, 2011, at 4:27 PM, Eric Gorr wrote:
> Well, it turned out to be not that bad to check the version numbers. The
> trick was to use CFBundleCopyInfoDictionaryForURL so one could get the
> info.plist from the helper tool. In any case, for those who might be
> interested, I have included the code below I used to check the installed
> helper tool vs. the current helper tool version for the SMJobBless sample
> application. If there is a better way, I would be interested.
>
> I suppose one more additional check that might need to be made is to verify
> that a connection to the tool can actually be made if the versions do match.
> It would seem possible that a different tool with the same name and version
> might exist. So, it would seem to be a good idea to check the signing
> requirement for the helper tool. In the case of the SMJobBless sample code,
> this is what I have so far:
> Or, is this check not necessary?
>
>
> -
> -
>
> NSDictionary* installedHelperJobData = (NSDictionary*)SMJobCopyDictionary(
> kSMDomainSystemLaunchd, (CFStringRef)@"com.apple.bsd.SMJobBlessHelper" );
> BOOLneedToInstall = YES;
>
> if ( installedHelperJobData )
> {
>NSLog( @"helperJobData: %@", installedHelperJobData );
>
>NSString* installedPath = [[installedHelperJobData
> objectForKey:@"ProgramArguments"] objectAtIndex:0];
>NSURL* installedPathURL= [NSURL
> fileURLWithPath:installedPath];
>
>NSDictionary* installedInfoPlist =
> (NSDictionary*)CFBundleCopyInfoDictionaryForURL( (CFURLRef)installedPathURL );
>NSString* installedBundleVersion = [installedInfoPlist
> objectForKey:@"CFBundleVersion"];
>NSInteger installedVersion= [installedBundleVersion
> integerValue];
>
>NSLog( @"installedVersion: %ld", (long)installedVersion );
>
>NSBundle* appBundle = [NSBundle mainBundle];
>NSURL* appBundleURL= [appBundle bundleURL];
>
>NSLog( @"appBundleURL: %@", appBundleURL );
>
>NSURL* currentHelperToolURL= [appBundleURL
> URLByAppendingPathComponent:@"Contents/Library/LaunchServices/com.apple.bsd.SMJobBlessHelper"];
>NSDictionary* currentInfoPlist=
> (NSDictionary*)CFBundleCopyInfoDictionaryForURL(
> (CFURLRef)currentHelperToolURL );
>NSString* currentBundleVersion= [currentInfoPlist
> objectForKey:@"CFBundleVersion"];
>NSInteger currentVersion = [currentBundleVersion
> integerValue];
>
>NSLog( @"currentVersion: %ld", (long)currentVersion );
>
>if ( currentVersion == installedVersion )
>{
>needToInstall = NO;
>}
> }
>
>
> On Sep 30, 2011, at 3:09 PM, Eric Gorr wrote:
>
>> So, it looks like one can call SMJobCopyDictionary with
>> kSMDomainSystemLaunchd and, in the case of the SMJobBless sample code,
>> com.apple.bsd.SMJobBlessHelper to determine whether or not the helper tool
>> has been installed.
>>
>> What I am still not sure about is how to check the version number of the
>> tool to see if I need to call SMJobBless again to update the helper tool.
>>
>> I suppose I could encode the version in the label of the tool. So, in the
>> case of the SMJobBless code, one might have:
>>
>> com.apple.bsd.SMJobBlessHelper.3
>>
>> or something, but I'm guessing there is a better solution then this.
>>
>>
>>
>> On Sep 30, 2011, at 1:53 PM, Eric Gorr wrote:
>>
>>> That's interesting.
>>>
>>> So, how would one go about checking to see whether or not SMJobBless needed
>>> to be called?
>>>
>>> I suppose one would need to check the version number of the installed job
>>> vs. the one in the application package.
>>>
>>> I also suppose one would also try to connect with the helper tool and, if
>>> that fails, then call SMJobBless.
>>>
>>>
>>>
>>> On Sep 30, 2011, at 1:40 PM, Kyle Sluder wrote:
>>>
Re: Managed Object Model versions
Nevermind, what you said sparked a light bulb. I'm looking at the code in my app delegate now. I think I'm on the right track. Thanks for your help! Regards, Luke On September 30, 2011, at 15:31 , Luke Sneeringer wrote: > Hmm. I never did that...but perhaps that's my problem? > > My code looks like... > > MyAppDelegate* delegate = [[NSApplication sharedApplication] delegate]; > NSManagedObjectContext* db = [delegate managedObjectContext]; > NSEntityDescription* entity = [NSEntityDescription entityForName: > @"MyObject" inManagedObjectContext: db]; > MyObject* object = [[MyObject alloc] initWithEntity: entity > insertIntoManagedObjectContext: db]; > > Am I missing something? I want to learn. :) > > Regards, > Luke Sneeringer > > On September 30, 2011, at 7:11 , Heath Borders wrote: > >> You specify a URL for the persistent store when you create it. Just find the >> store at that URL. >> >> -Heath >> >> On Sep 30, 2011 12:33 AM, "Luke Sneeringer" wrote: >> > Hey all, >> > I am working on writing my first Core Data application. I made an entity, >> > did some work to test it, and then made another (linked) entity. >> > The problem is now I'm totally stuck, because when I try to do anything >> > that affects Core Data, I get a completely unhelpful error message: >> > >> > "The managed object model version used to open the persistent store is >> > incompatible with the one that was used to create the persistent store." >> > >> > Well, I Googled this, and there's some discussion about making migrations. >> > I don't want to do that. I just want to blow away the old data store -- >> > get it out of the filesystem and have the application make a new one. >> > However, I can't figure out how to do this. I found a blog entry >> > suggesting that I look in ~/Library/Application Support/Application Name/, >> > but my application doesn't seem to have made a folder in >> > ~/Library/Application Support/ at all. >> > >> > So...how can I get rid of my old persistent store? It doesn't have to be >> > programmatic -- in fact, I'd prefer it not be programmatic. I just want to >> > wipe it off the disk. >> > >> > Help! >> > >> > Thanks, >> > Luke Sneeringer___ >> > >> > 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/heath.borders%40gmail.com >> > >> > This email sent to heath.bord...@gmail.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
Re: Managed Object Model versions
Hmm. I never did that...but perhaps that's my problem? My code looks like... MyAppDelegate* delegate = [[NSApplication sharedApplication] delegate]; NSManagedObjectContext* db = [delegate managedObjectContext]; NSEntityDescription* entity = [NSEntityDescription entityForName: @"MyObject" inManagedObjectContext: db]; MyObject* object = [[MyObject alloc] initWithEntity: entity insertIntoManagedObjectContext: db]; Am I missing something? I want to learn. :) Regards, Luke Sneeringer On September 30, 2011, at 7:11 , Heath Borders wrote: > You specify a URL for the persistent store when you create it. Just find the > store at that URL. > > -Heath > > On Sep 30, 2011 12:33 AM, "Luke Sneeringer" wrote: > > Hey all, > > I am working on writing my first Core Data application. I made an entity, > > did some work to test it, and then made another (linked) entity. > > The problem is now I'm totally stuck, because when I try to do anything > > that affects Core Data, I get a completely unhelpful error message: > > > > "The managed object model version used to open the persistent store is > > incompatible with the one that was used to create the persistent store." > > > > Well, I Googled this, and there's some discussion about making migrations. > > I don't want to do that. I just want to blow away the old data store -- get > > it out of the filesystem and have the application make a new one. > > However, I can't figure out how to do this. I found a blog entry suggesting > > that I look in ~/Library/Application Support/Application Name/, but my > > application doesn't seem to have made a folder in ~/Library/Application > > Support/ at all. > > > > So...how can I get rid of my old persistent store? It doesn't have to be > > programmatic -- in fact, I'd prefer it not be programmatic. I just want to > > wipe it off the disk. > > > > Help! > > > > Thanks, > > Luke Sneeringer___ > > > > 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/heath.borders%40gmail.com > > > > This email sent to heath.bord...@gmail.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
Re: Question about SMJobBless
Well, it turned out to be not that bad to check the version numbers. The trick
was to use CFBundleCopyInfoDictionaryForURL so one could get the info.plist
from the helper tool. In any case, for those who might be interested, I have
included the code below I used to check the installed helper tool vs. the
current helper tool version for the SMJobBless sample application. If there is
a better way, I would be interested.
I suppose one more additional check that might need to be made is to verify
that a connection to the tool can actually be made if the versions do match. It
would seem possible that a different tool with the same name and version might
exist. So, it would seem to be a good idea to check the signing requirement for
the helper tool. In the case of the SMJobBless sample code, this is what I have
so far:
-
-
SecRequirementRef requirement;
OSStatusstErr;
stErr = SecRequirementCreateWithString( CFSTR( "identifier
com.apple.bsd.SMJobBlessHelper and certificate leaf[subject.CN] = \"Joe
Developer\"" ), kSecCSDefaultFlags, &requirement );
SecCodeRef theCode;
stErr = SecCodeCheckValidity( theCode, kSecCSDefaultFlags, requirement );
-
-
However, I am not sure how to get the SecCodeRef for the installed helper tool.
Any suggestions on how I can do that?
Or, is this check not necessary?
-
-
NSDictionary* installedHelperJobData = (NSDictionary*)SMJobCopyDictionary(
kSMDomainSystemLaunchd, (CFStringRef)@"com.apple.bsd.SMJobBlessHelper" );
BOOLneedToInstall = YES;
if ( installedHelperJobData )
{
NSLog( @"helperJobData: %@", installedHelperJobData );
NSString* installedPath = [[installedHelperJobData
objectForKey:@"ProgramArguments"] objectAtIndex:0];
NSURL* installedPathURL= [NSURL
fileURLWithPath:installedPath];
NSDictionary* installedInfoPlist =
(NSDictionary*)CFBundleCopyInfoDictionaryForURL( (CFURLRef)installedPathURL );
NSString* installedBundleVersion = [installedInfoPlist
objectForKey:@"CFBundleVersion"];
NSInteger installedVersion= [installedBundleVersion
integerValue];
NSLog( @"installedVersion: %ld", (long)installedVersion );
NSBundle* appBundle = [NSBundle mainBundle];
NSURL* appBundleURL= [appBundle bundleURL];
NSLog( @"appBundleURL: %@", appBundleURL );
NSURL* currentHelperToolURL= [appBundleURL
URLByAppendingPathComponent:@"Contents/Library/LaunchServices/com.apple.bsd.SMJobBlessHelper"];
NSDictionary* currentInfoPlist=
(NSDictionary*)CFBundleCopyInfoDictionaryForURL( (CFURLRef)currentHelperToolURL
);
NSString* currentBundleVersion= [currentInfoPlist
objectForKey:@"CFBundleVersion"];
NSInteger currentVersion = [currentBundleVersion
integerValue];
NSLog( @"currentVersion: %ld", (long)currentVersion );
if ( currentVersion == installedVersion )
{
needToInstall = NO;
}
}
On Sep 30, 2011, at 3:09 PM, Eric Gorr wrote:
> So, it looks like one can call SMJobCopyDictionary with
> kSMDomainSystemLaunchd and, in the case of the SMJobBless sample code,
> com.apple.bsd.SMJobBlessHelper to determine whether or not the helper tool
> has been installed.
>
> What I am still not sure about is how to check the version number of the tool
> to see if I need to call SMJobBless again to update the helper tool.
>
> I suppose I could encode the version in the label of the tool. So, in the
> case of the SMJobBless code, one might have:
>
> com.apple.bsd.SMJobBlessHelper.3
>
> or something, but I'm guessing there is a better solution then this.
>
>
>
> On Sep 30, 2011, at 1:53 PM, Eric Gorr wrote:
>
>> That's interesting.
>>
>> So, how would one go about checking to see whether or not SMJobBless needed
>> to be called?
>>
>> I suppose one would need to check the version number of the installed job
>> vs. the one in the application package.
>>
>> I also suppose one would also try to connect with the helper tool and, if
>> that fails, then call SMJobBless.
>>
>>
>>
>> On Sep 30, 2011, at 1:40 PM, Kyle Sluder wrote:
>>
>>> On Sep 30, 2011, at 10:05 AM, Eric Gorr wrote:
>>>
On Sep 30, 2011, at 1:00 PM, Jean-Daniel Dupas wrote:
> As I understand it, you have to bless the job only once, not at each
> launch, so you shouldn't have to request the authorization each time.
It would be interesting if that is how it actually works, but I am quite
certain it doesn't work that way.
>>>
>>> It does. SMJobBless submits a blessed plist to launchd. It does not do
>>> one-off jobs. You use once it to install a privileged launchd task that you
>>> can talk to in the future.
>>>
>>> --Kyle Sluder
>>
>> ___
>>
>> Cocoa-dev mailing list (Cocoa-dev@lists
Re: Core Data : Undo Delete : Cannot fulfill a fault
I've found the workaround, at least. Objects are in a tree formation with parent and children relationships. Delete Rule is Cascade. Steps to reproduce: • Open a particular document which contains 4 objects Root1 OldObject2 OldObject3 OldObject4 • Insert 3 new objects, so the tree is now Root1 OldObject2 OldObject3 NewObject5 NewObject6 NewObject7 OldObject4 • Save • Delete the 3 new objects • Save • Undo The trick is the order in which they are deleted. If the child NewObject7 is deleted before its parent NewObject6, Undo will succeed. If the parent is deleted first, Undo will fail. In my app, the order is random due to enumerating an NSSet. I think I remember seeing, when looking at the invocation on the undo stack earlier today, in that NSKnownKeysDictionary1, that the 'parent' relationship of the un-restorable object was null. But all properties in my data model are optional. Been there and done that with Core Data's validation :( Some stumpers: • If I consolidate the first three steps, opening a document which already contains all 7 objects, Undo always succeeds. • If I skip the second Save step, Undo always succeeds. ___ 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
Re: Core Data + Undo + Autosave = Instability?
On 2011 Sep 30, at 09:42, Jim Correia wrote: > But you have a pretty reliable way to reproduce the bug, right? Thank you, Jim. Yes, it takes several minutes but is scripted. > Have you broken at the point of objc_exception_throw for the > NSObjectInaccessibleException and examined what, specifically, is firing the > fault? Yes. I was wrong about attributes not being in the invocation – see below. #0 0x962250c0 in objc_exception_throw #1 0x94c6a891 in _PFFaultHandlerLookupRow #2 0x94c9b5df in -[NSFaultHandler fulfillFault:withContext:] #3 0x94c796b3 in -[NSManagedObject(_NSInternalMethods) _newPropertiesForRetainedTypes:andCopiedTypes:preserveFaults:] #4 0x94c7965f in -[NSManagedObject(_NSInternalMethods) _newAllPropertiesWithRelationshipFaultsIntact__] #5 0x94c7954e in -[NSManagedObjectContext(_NSInternalChangeProcessing) _establishEventSnapshotsForObject:] #6 0x94c79465 in _PFFastMOCObjectWillChange #7 0x94cd7019 in -[NSManagedObjectContext(_NSInternalChangeProcessing) _undoUpdates:] #8 0x9021effd in __invoking___ #9 0x9021ef39 in -[NSInvocation invoke] #10 0x9021f08a in -[NSInvocation invokeWithTarget:] #11 0x001be1b9 in -[GCConcreteUndoTask perform] at GCUndoManager.m:1496 Thanks to Graham Cox, I have code for [GCConcreteUndoTask perform]. I also have a category on NSInvocation which gives me a -longDescription of its properties: target = The document's (and Undo Manager's) managed object context selector = _undoUpdates: The argument of _undoUpdates: is an array containing 4 objects object at index 0: the deleted object, with a retainCount of 9, whose data is object at index 1: an instance of NSKnownKeysDictionary1, whose keys and values are the keys and values of the deleted object before it was faulted. Its retainCount is 9. object at index 2: an instance of NSNull object at index 3: an instance of NSNumber whose value is 1 > Start here and work backwards and you may be able to infer why someone has a > reference to a stale object. I've never seen a precise definition of the word "stale" in Core Data. The object in question has a retainCount of 9, and it is faulted. Does that mean it's "stale"? > At the very least you’ll know who. It seems that NSManagedObjectContext seems to have all the information it needs to un-fault the object, but won't do it for some reason. ___ 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
Re: Question about SMJobBless
So, it looks like one can call SMJobCopyDictionary with kSMDomainSystemLaunchd and, in the case of the SMJobBless sample code, com.apple.bsd.SMJobBlessHelper to determine whether or not the helper tool has been installed. What I am still not sure about is how to check the version number of the tool to see if I need to call SMJobBless again to update the helper tool. I suppose I could encode the version in the label of the tool. So, in the case of the SMJobBless code, one might have: com.apple.bsd.SMJobBlessHelper.3 or something, but I'm guessing there is a better solution then this. On Sep 30, 2011, at 1:53 PM, Eric Gorr wrote: > That's interesting. > > So, how would one go about checking to see whether or not SMJobBless needed > to be called? > > I suppose one would need to check the version number of the installed job vs. > the one in the application package. > > I also suppose one would also try to connect with the helper tool and, if > that fails, then call SMJobBless. > > > > On Sep 30, 2011, at 1:40 PM, Kyle Sluder wrote: > >> On Sep 30, 2011, at 10:05 AM, Eric Gorr wrote: >> >>> On Sep 30, 2011, at 1:00 PM, Jean-Daniel Dupas wrote: >>> As I understand it, you have to bless the job only once, not at each launch, so you shouldn't have to request the authorization each time. >>> >>> It would be interesting if that is how it actually works, but I am quite >>> certain it doesn't work that way. >> >> It does. SMJobBless submits a blessed plist to launchd. It does not do >> one-off jobs. You use once it to install a privileged launchd task that you >> can talk to in the future. >> >> --Kyle Sluder > > ___ > > 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/mailist%40ericgorr.net > > This email sent to mail...@ericgorr.net ___ 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
Re: Window Display
On Sep 30, 2011, at 09:21, koko wrote: > I had asked about running a modal dialog at app start. > > Perhaps a different approach. All I need to do is not display the main > window until the modal finishes. I have set in IB visible at launch no. > Perhaps I do not understand this setting as the main window displays without > any specific 'call' by he app. If you turned off the "Visible at launch" setting for that specific window, there must be some generated code that makes it key and visible, otherwise, it shouldn't show up. -Laurent. -- Laurent Daudelin AIM/iChat/Skype:LaurentDaudelin http://www.nemesys-soft.com/ Logiciels Nemesys Software laur...@nemesys-soft.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
Re: Question about SMJobBless
That's interesting. So, how would one go about checking to see whether or not SMJobBless needed to be called? I suppose one would need to check the version number of the installed job vs. the one in the application package. I also suppose one would also try to connect with the helper tool and, if that fails, then call SMJobBless. On Sep 30, 2011, at 1:40 PM, Kyle Sluder wrote: > On Sep 30, 2011, at 10:05 AM, Eric Gorr wrote: > >> On Sep 30, 2011, at 1:00 PM, Jean-Daniel Dupas wrote: >> >>> As I understand it, you have to bless the job only once, not at each >>> launch, so you shouldn't have to request the authorization each time. >> >> It would be interesting if that is how it actually works, but I am quite >> certain it doesn't work that way. > > It does. SMJobBless submits a blessed plist to launchd. It does not do > one-off jobs. You use once it to install a privileged launchd task that you > can talk to in the future. > > --Kyle Sluder ___ 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
Re: Question about SMJobBless
On Sep 30, 2011, at 10:05 AM, Eric Gorr wrote: > On Sep 30, 2011, at 1:00 PM, Jean-Daniel Dupas wrote: > >> As I understand it, you have to bless the job only once, not at each launch, >> so you shouldn't have to request the authorization each time. > > It would be interesting if that is how it actually works, but I am quite > certain it doesn't work that way. It does. SMJobBless submits a blessed plist to launchd. It does not do one-off jobs. You use once it to install a privileged launchd task that you can talk to in the future. --Kyle Sluder___ 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
Re: Question about SMJobBless
On Sep 30, 2011, at 1:00 PM, Jean-Daniel Dupas wrote: > Le 30 sept. 2011 à 18:14, Eric Gorr a écrit : > >> >> On Sep 30, 2011, at 10:34 AM, Jean-Daniel Dupas wrote: >> >>> >>> Le 30 sept. 2011 à 16:01, Eric Gorr a écrit : >>> I had a couple of followup questions concerning the approach used by SMJobBless in developing a secure helper tool. In the How It Works section in the ReadMe, it states: 4. Requiring the user to authorize the privileged helper tool only once the first time it's used This is what I believe led to my confusion on why the app continues to ask for the password every time I launch it. However, this statement actually refers to the need to just ask for the password once at application launch and have the authorization remain valid while the application is running. Is this correct? I am also wondering how it might be possible to only ask for an admin password once as an absolute regardless of the number of time the application was launched. Is this possible? If so, how? >>> >>> According the the SMJobBless (the function not the sample code) reference, >>> it installs a launchd plist . So you need to auth only once to install the >>> plist, not one time per application launch. >> >> I'm sorry, I don't see that in the documentation. An AuthorizationRef needs >> to be passed to SMJobBless with the kSMRightBlessPrivilegedHelper right. To >> get this right, one calls AuthorizationCreate and it is AuthorizationCreate >> that requests the password with each launch of the application. > > As I understand it, you have to bless the job only once, not at each launch, > so you shouldn't have to request the authorization each time. It would be interesting if that is how it actually works, but I am quite certain it doesn't work that way. ___ 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
Re: Question about SMJobBless
Le 30 sept. 2011 à 18:14, Eric Gorr a écrit : > > On Sep 30, 2011, at 10:34 AM, Jean-Daniel Dupas wrote: > >> >> Le 30 sept. 2011 à 16:01, Eric Gorr a écrit : >> >>> I had a couple of followup questions concerning the approach used by >>> SMJobBless in developing a secure helper tool. >>> >>> In the How It Works section in the ReadMe, it states: >>> >>> 4. Requiring the user to authorize the privileged helper tool only once the >>> first time it's used >>> >>> This is what I believe led to my confusion on why the app continues to ask >>> for the password every time I launch it. >>> >>> However, this statement actually refers to the need to just ask for the >>> password once at application launch and have the authorization remain valid >>> while the application is running. Is this correct? >>> >>> >>> I am also wondering how it might be possible to only ask for an admin >>> password once as an absolute regardless of the number of time the >>> application was launched. Is this possible? If so, how? >>> >> >> According the the SMJobBless (the function not the sample code) reference, >> it installs a launchd plist . So you need to auth only once to install the >> plist, not one time per application launch. > > I'm sorry, I don't see that in the documentation. An AuthorizationRef needs > to be passed to SMJobBless with the kSMRightBlessPrivilegedHelper right. To > get this right, one calls AuthorizationCreate and it is AuthorizationCreate > that requests the password with each launch of the application. As I understand it, you have to bless the job only once, not at each launch, so you shouldn't have to request the authorization each time. -- Jean-Daniel ___ 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
Re: Core Data : Undo Delete : Cannot fulfill a fault
On Sep 30, 2011, at 5:41 AM, Jerry Krinock wrote: > I'm still working on this issue, trying to find the trigger which moves my > corner case into the corner, hoping for a workaround. It's tedious because > of different operations and states. But you have a pretty reliable way to reproduce the bug, right? Have you taken my previous advice? Have you broken at the point of objc_exception_throw for the NSObjectInaccessibleException and examined what, specifically, is firing the fault? Start here and work backwards and you may be able to infer why someone has a reference to a stale object. At the very least you’ll know who. (You’ve already got the type and ID of the stale object.) > The implication of the last two points is that Core Data implements Undo > quite on its own; the undo manager acts as little more than a counter. I'm not sure how you jumped to this conclusion. Core Data is recording invocations in NSUndoManager in much the same way you'd do if you were using NSUndoManager directly. —Jim ___ 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
Window Display
I had asked about running a modal dialog at app start. Perhaps a different approach. All I need to do is not display the main window until the modal finishes. I have set in IB visible at launch no. Perhaps I do not understand this setting as the main window displays without any specific 'call' by he app. Is it possible to suppress the main window display until a desired time? -koko___ 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
Re: NSDocument Serialization (-performSynchronousFileAccessUsingBlock: and friends)
On Sep 30, 2011, at 8:47 AM, Kevin Perry wrote: > On Sep 29, 2011, at 4:41 PM, Kyle Sluder wrote: > >> [...snip...] >> >> A general issue I have with asynchronous saving: what if the save >> operation fails? The user has now made additional changes, but their >> "Save a Version" operation did not create a version for them. So now >> they can't roll back to the timepoint they thought they created. > > That is true. Perhaps this is something that could be improved in the future. > I suppose one way to fix this would be to retain the 'snapshot' used for > async saving and retry again later? Alternatively, an application may choose to opt out of asynchronous saving for NSSaveOperations only. -KP___ 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
Re: Question about SMJobBless
On Sep 30, 2011, at 10:34 AM, Jean-Daniel Dupas wrote: > > Le 30 sept. 2011 à 16:01, Eric Gorr a écrit : > >> I had a couple of followup questions concerning the approach used by >> SMJobBless in developing a secure helper tool. >> >> In the How It Works section in the ReadMe, it states: >> >> 4. Requiring the user to authorize the privileged helper tool only once the >> first time it's used >> >> This is what I believe led to my confusion on why the app continues to ask >> for the password every time I launch it. >> >> However, this statement actually refers to the need to just ask for the >> password once at application launch and have the authorization remain valid >> while the application is running. Is this correct? >> >> >> I am also wondering how it might be possible to only ask for an admin >> password once as an absolute regardless of the number of time the >> application was launched. Is this possible? If so, how? >> > > According the the SMJobBless (the function not the sample code) reference, it > installs a launchd plist . So you need to auth only once to install the > plist, not one time per application launch. I'm sorry, I don't see that in the documentation. An AuthorizationRef needs to be passed to SMJobBless with the kSMRightBlessPrivilegedHelper right. To get this right, one calls AuthorizationCreate and it is AuthorizationCreate that requests the password with each launch of the application.___ 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
Re: NSDocument Serialization (-performSynchronousFileAccessUsingBlock: and friends)
On Sep 29, 2011, at 4:41 PM, Kyle Sluder wrote: > [...snip...] > > A general issue I have with asynchronous saving: what if the save > operation fails? The user has now made additional changes, but their > "Save a Version" operation did not create a version for them. So now > they can't roll back to the timepoint they thought they created. That is true. Perhaps this is something that could be improved in the future. I suppose one way to fix this would be to retain the 'snapshot' used for async saving and retry again later? > Of course I have another question. > > On Thu, Sep 29, 2011 at 12:33 PM, Kevin Perry wrote: >> NSDocument's NSFilePresenter methods use >> performAsynchronousFileAccessUsingBlock: internally, so if something else >> current has file access, the NSFileCoordinator requests are indeed blocked >> (or "enqueued"). > > What about NSFilePresenter methods that require presenting a sheet? Do > they instead wrap their calls to -performAsynchronousFileAccess: in a > call to -performActivityWithSynchronousWaiting:NO? Yes. -KP___ 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
Re: Question about SMJobBless
Le 30 sept. 2011 à 16:01, Eric Gorr a écrit : > I had a couple of followup questions concerning the approach used by > SMJobBless in developing a secure helper tool. > > In the How It Works section in the ReadMe, it states: > > 4. Requiring the user to authorize the privileged helper tool only once the > first time it's used > > This is what I believe led to my confusion on why the app continues to ask > for the password every time I launch it. > > However, this statement actually refers to the need to just ask for the > password once at application launch and have the authorization remain valid > while the application is running. Is this correct? > > > I am also wondering how it might be possible to only ask for an admin > password once as an absolute regardless of the number of time the application > was launched. Is this possible? If so, how? > According the the SMJobBless (the function not the sample code) reference, it installs a launchd plist . So you need to auth only once to install the plist, not one time per application launch. > Thank you. > > On Sep 29, 2011, at 4:45 PM, Eric Gorr wrote: > >> I cannot seem to locate any documentation on this, so hopefully someone can >> confirm the behavior I am seeing with Apple's sample SMJobBless code located >> at: >> >> http://developer.apple.com/library/mac/#samplecode/SMJobBless/Introduction/Intro.html#//apple_ref/doc/uid/DTS40010071 >> >> I was under the impression that it would only ask for an admin password if >> it detected a that a new version of the helper tool needed to be installed. >> >> However, this impression is apparently incorrect. >> >> The behavior I am seeing under 10.6 is that if I launch the app for the >> first time, it will ask for the password. If I launch almost immediately, it >> won't. However, if I wait a long enough time, it will ask for the password >> again. During all of this, the helper tool does not change. >> >> Can anyone point to documentation that defines this as the correct behavior? >> >> Thank you. >> > > ___ > > 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/devlists%40shadowlab.org > > This email sent to devli...@shadowlab.org -- Jean-Daniel ___ 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
Re: Question about SMJobBless
If you want answer, you should try the darwin-dev list. SMJobBless is not cocoa specific, and so is off-topic on this list, and IIRC, the engineer in charge of the ServiceManagement framework is a darwin-dev subscriber. Le 30 sept. 2011 à 16:01, Eric Gorr a écrit : > I had a couple of followup questions concerning the approach used by > SMJobBless in developing a secure helper tool. > > In the How It Works section in the ReadMe, it states: > > 4. Requiring the user to authorize the privileged helper tool only once the > first time it's used > > This is what I believe led to my confusion on why the app continues to ask > for the password every time I launch it. > > However, this statement actually refers to the need to just ask for the > password once at application launch and have the authorization remain valid > while the application is running. Is this correct? > > > I am also wondering how it might be possible to only ask for an admin > password once as an absolute regardless of the number of time the application > was launched. Is this possible? If so, how? > > Thank you. > > On Sep 29, 2011, at 4:45 PM, Eric Gorr wrote: > >> I cannot seem to locate any documentation on this, so hopefully someone can >> confirm the behavior I am seeing with Apple's sample SMJobBless code located >> at: >> >> http://developer.apple.com/library/mac/#samplecode/SMJobBless/Introduction/Intro.html#//apple_ref/doc/uid/DTS40010071 >> >> I was under the impression that it would only ask for an admin password if >> it detected a that a new version of the helper tool needed to be installed. >> >> However, this impression is apparently incorrect. >> >> The behavior I am seeing under 10.6 is that if I launch the app for the >> first time, it will ask for the password. If I launch almost immediately, it >> won't. However, if I wait a long enough time, it will ask for the password >> again. During all of this, the helper tool does not change. >> >> Can anyone point to documentation that defines this as the correct behavior? >> >> Thank you. >> > > ___ > > 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/devlists%40shadowlab.org > > This email sent to devli...@shadowlab.org -- Jean-Daniel ___ 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
Re: Question about SMJobBless
I had a couple of followup questions concerning the approach used by SMJobBless in developing a secure helper tool. In the How It Works section in the ReadMe, it states: 4. Requiring the user to authorize the privileged helper tool only once the first time it's used This is what I believe led to my confusion on why the app continues to ask for the password every time I launch it. However, this statement actually refers to the need to just ask for the password once at application launch and have the authorization remain valid while the application is running. Is this correct? I am also wondering how it might be possible to only ask for an admin password once as an absolute regardless of the number of time the application was launched. Is this possible? If so, how? Thank you. On Sep 29, 2011, at 4:45 PM, Eric Gorr wrote: > I cannot seem to locate any documentation on this, so hopefully someone can > confirm the behavior I am seeing with Apple's sample SMJobBless code located > at: > > http://developer.apple.com/library/mac/#samplecode/SMJobBless/Introduction/Intro.html#//apple_ref/doc/uid/DTS40010071 > > I was under the impression that it would only ask for an admin password if it > detected a that a new version of the helper tool needed to be installed. > > However, this impression is apparently incorrect. > > The behavior I am seeing under 10.6 is that if I launch the app for the first > time, it will ask for the password. If I launch almost immediately, it won't. > However, if I wait a long enough time, it will ask for the password again. > During all of this, the helper tool does not change. > > Can anyone point to documentation that defines this as the correct behavior? > > Thank you. > ___ 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
-(BOOL)acceptsFirstResponder and -(BOOL)becomeFirstResponder 's return values are ignored
Hello I have an editable NSTextField subclass, which overrides these two methods and returns NO there. I have placed an Edit Box (nstextfield) in Interface Builder, whose class is set to this custom subclass with these two overridden nsresponder methods. when I run the application, I can still set focus on this edit box even though the methods -(BOOL)acceptsFirstResponder and -(BOOL)becomeFirstResponder get called (i checked that with NSLog). But, despite me returning NO, i can click on this control with mouse and type text in there. This is an NSDocument based application. What may be wrong? Why does Cocoa ignore NO'es? Is there any higher-priority methods that I need to override? Interesting that in a "clean" application (i created one from scratch just to see if this should work at all) it works - the user can't click on the edit box. But not in this nsdocument based application. Thanks ___ 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
Re: Finder Integration
On 30/09/2011, at 09:43, cocoa-dev-requ...@lists.apple.com wrote: > From: Matt Gough > Date: 30 de setembro de 2011 05:21:06 BRT > > Firstly there is no official way to do this, all the solutions you see in the > wild are hacks of one sort or another. > > Having said that, I had to implement what you are asking for (overlays on > icons) and did it via SIMBL. Unfortunately I can't share code or say too much > about what what is needed, but it would certainly help if you understood > method swizzling and found a way to dump all the Obj_c classes that the > Finder uses internally. > > On 29 Sep 2011, at 20:39, Damon Allison wrote: >> I am researching options for integrating with Finder. In particular, I would >> like my application to provide file and directory icon overlays similar to >> how Dropbox.app overlays green and blue images on top of file and folder >> images. I've never used Dropbox, but - on the offhand chance that you want overlays only on certain icons, not generic ones - you can add overlays by adding a 'badg' resource to the file's resource fork (or to the hidden .icon\r file inside the folder). Check out: http://developer.apple.com/legacy/mac/library/documentation/Carbon/Conceptual/Icon_Service_nd_Utilities/IconServUtili.pdf and http://www.cocoabuilder.com/archive/cocoa/95797-finder-icon-badging.html HTH, -- Rainer Brockerhoff Belo Horizonte, Brazil "In the affairs of others even fools are wise In their own business even sages err." Weblog: http://www.brockerhoff.net/blog ___ 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
Performance of a crossfade
I am currently performing image crossfades using the following method:
*
- (void)crossFadeMainImage:(UIImage *)image1 toImage:(UIImage *)image2 {
CABasicAnimation *crossFade = [CABasicAnimation animationWithKeyPath:@
"contents"];
crossFade.duration = 0.5;
crossFade.delegate = self;
crossFade.fromValue = (id)image1.CGImage;
crossFade.toValue = (id)image2.CGImage;
[self.mainImage.layer addAnimation:crossFade forKey:@"animateContents"];
self.mainImage.image = image2;
}
*
It works wonderfully, however the performance to begin the fade takes a
little while (under a second but it's not instant). The UIImageView is
nearly full screen on an iPad & the images are larger than that because the
UIImageView is within a UIScrollView that allows zooming and panning (want
to keep the image quality up when zoomed in).
Is there something that could be done to make this happen a little quicker?
I am using ARC.
Thanks,
Eric
___
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
Re: Core Data : Undo Delete : Cannot fulfill a fault
On 2011 Sep 30, at 00:06, Quincey Morris wrote: > However, there are a number of well-known examples of outrageousness. The > most relevant one that I can think of is that NSPersistentDocument was > originally released without (and may still not have, for all I know) support > for NSDocument's "Save To…" behavior, as well as "Save As…" behavior that > (apparently) went only as far as a successful default migration could carry > it. and then there's the outrageousness that, when you 'Revert' an NSPersistentDocument, unlike NSDocument, it closes and re-opens the window. I wish Quincey was wrong but I'm afraid he's correct. * * * Oh, another thing. Although my app is using Autosave in Place and Asynchronous Saving, the problem persists if I switch these off. As it turns out, though, Asynchronous Saving + NSPersistentDocument is *another* issue. * * * I'm still working on this issue, trying to find the trigger which moves my corner case into the corner, hoping for a workaround. It's tedious because of different operations and states. Repeating what I've already posted, • There is a chance that it could still be my code. • The deleted objects are definitely *not* being deallocced. • There are no object attributes in the invocations on the undo stack. • The heavy lifting is apparently done by -[NSManagedObjectContext _undoUpdates]. The implication of the last two points is that Core Data implements Undo quite on its own; the undo manager acts as little more than a counter. Of course, if I can find a workaround and/or isolate to a demo I shall post, file a bug, etc.. ___ 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
Re: Managed Object Model versions
You specify a URL for the persistent store when you create it. Just find the store at that URL. -Heath On Sep 30, 2011 12:33 AM, "Luke Sneeringer" wrote: > Hey all, > I am working on writing my first Core Data application. I made an entity, did some work to test it, and then made another (linked) entity. > The problem is now I'm totally stuck, because when I try to do anything that affects Core Data, I get a completely unhelpful error message: > > "The managed object model version used to open the persistent store is incompatible with the one that was used to create the persistent store." > > Well, I Googled this, and there's some discussion about making migrations. I don't want to do that. I just want to blow away the old data store -- get it out of the filesystem and have the application make a new one. > However, I can't figure out how to do this. I found a blog entry suggesting that I look in ~/Library/Application Support/Application Name/, but my application doesn't seem to have made a folder in ~/Library/Application Support/ at all. > > So...how can I get rid of my old persistent store? It doesn't have to be programmatic -- in fact, I'd prefer it not be programmatic. I just want to wipe it off the disk. > > Help! > > Thanks, > Luke Sneeringer___ > > 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/heath.borders%40gmail.com > > This email sent to heath.bord...@gmail.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
Re: creating multiple NSTimers
Thanks for the discussion. What I implemented last night was what Graham had suggested. I simply bind my table column values to an NSArrayController controller and observed by KVO in my set box object. It works great. I think this is also what Conrad had meant as well. Simply changing the time updates or invalidates the timer for each box. It is far more elegant that what I was originally doing. Not to carry this discussion too long, I created this confusion in my head by looking at a project I did 4 years ago while developing a sprinkler controller. In that project I ended up creating a schedule object which was a property for each relay on a controller board which was as an object as well. Each relay (sprinkler zone) had an address, on and off commands and an indeterminate number of schedule objects as properties. If you think about this it is quite challenging as you can very easily end up with 100's of timers on the run loop at any one time. Many of these timers (on a 7 day schedule) would be sitting around for days waiting to fire. For just one relay you would have at a minimum 2 timers (on and off timers) a day. Each relay was on a relay board with 12 relays. Complicating matters was the fact that here (drought stricken Texas) many areas are running a sprinkler zone at multiple short interval times per day (mainly at night). To avoid having all of these timers on the run loop I ended up using the one initial timer that when fired started a loop through the array of timers. But keep in mind that each "on" command timer also had an "off" command timer as well as setting up the next on timer. Also keep in mind that only one zone can be on at a time due to water pressure (this being the difference between this set top box project and the sprinkler project). etc. Anyway food for thought. Tom On Sep 30, 2011, at 3:37 AM, Conrad Shultz wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 9/30/11 12:29 AM, Thomas Davie wrote: > >>> When the user updates a timer, one is forced to re-sort the >>> array and reposition the index (under the above implementation). >> >> Why would you need to resort? Just remove, and reinsert. > > OK, I'll grant you it's a fast re-sort, but you still have to find the > new insertion point and move the index (if needed). > >>> One would also have to implement the scheme carefully, >>> particularly if the shut-off code is offloaded onto separate >>> threads, to avoid potential race conditions arising from a user >>> changing a fire date in the middle of a shut-off sequence. >> >> Careful locking required in multithreaded environment – >> unsurprising. > > Of course, though my gut feeling (admittedly happening at a time of > day where I'm fast fading and likely to put my foot in my mouth...) is > that the locking would be simpler if one had discrete timers that can > be scattered across threads (or run their invocations on separate > threads - though that might be unsuitable for the task at hand). I > haven't sat down and implemented this (as you evidently have), so I > must confess I don't have much to stand on here. > >>> And as Graham mentioned, polling is probably less CPU and power >>> efficient than using timers anyway. >> >> Who's suggesting polling - you simply have one timer set for the >> time at which the first of your actual timers goes off. When it >> goes off, you fire the first of your actual timers, and reschedule >> your "when do other timers go off" timer. > > OK, my apologies, I got turned around and had the earlier suggestion > about a high-resolution poll still stuck in my head. You're > absolutely right - no one is suggesting polling in the above. > >>> Am I missing something conceptually here? Why are people >>> pushing for the single timer model? Is there some hidden >>> complexity in a multi-timer approach that I'm not seeing? >> >> I implemented the single timer model yesterday, but I have to >> admit, the reason was because I'm targeting GNUstep, and when I >> stared at their source I discovered that they simply itterate >> through *all* timers every run loop iteration checking if they've >> gone off, their code also starts NSLogging warnings if you have >> more than 1000 timers. I have no idea if apple's solution is >> better than GNUstep's, but if it isn't, the single timer approach >> would be vastly beneficial. > > Wow, I have to imagine there are a fair number of timers getting fired > off throughout the system all the time for various tasks and that > Apple would have optimized it more thoroughly. > > But a cursory inspection of the most recent open source CFRunLoop.c > suggests that indeed is what is happening inside __CFRunLoopDoTimers. > It's possible that I'm missing something in my tired state, but it > sure does look like a simple loop. (There's a lot of magic happening > in __CFRunLoopDoTimer, but it still gets called during each loop > iteration.) > > Huh... c
Re: Core Data : Undo Delete : Cannot fulfill a fault
On Sep 30, 2011, at 00:17 , Jim Correia wrote: > You are assuming that the only place this information can exist is in the row > cache itself. The information can exist anywhere. At the risk of > over-trivializing the problem—It’s just code™. > > All the information necessary to resurrect the object (or restore properties) > can be stored on the undo stack itself. Could be. I dunno. It doesn't "feel" right, though, and it also seems problematic. I don't quite get the point of faulting out a deleted object at save time if that also requires the discarded property information to be restructured into a different form and kept anyway. I don't see how deleted objects' objectIDs can survive a save without compromising the integrity of objectID uniquing across multiple MOCs. But I dunno. ___ 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
Re: creating multiple NSTimers
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 9/30/11 12:29 AM, Thomas Davie wrote: >> When the user updates a timer, one is forced to re-sort the >> array and reposition the index (under the above implementation). > > Why would you need to resort? Just remove, and reinsert. OK, I'll grant you it's a fast re-sort, but you still have to find the new insertion point and move the index (if needed). >> One would also have to implement the scheme carefully, >> particularly if the shut-off code is offloaded onto separate >> threads, to avoid potential race conditions arising from a user >> changing a fire date in the middle of a shut-off sequence. > > Careful locking required in multithreaded environment – > unsurprising. Of course, though my gut feeling (admittedly happening at a time of day where I'm fast fading and likely to put my foot in my mouth...) is that the locking would be simpler if one had discrete timers that can be scattered across threads (or run their invocations on separate threads - though that might be unsuitable for the task at hand). I haven't sat down and implemented this (as you evidently have), so I must confess I don't have much to stand on here. >> And as Graham mentioned, polling is probably less CPU and power >> efficient than using timers anyway. > > Who's suggesting polling - you simply have one timer set for the > time at which the first of your actual timers goes off. When it > goes off, you fire the first of your actual timers, and reschedule > your "when do other timers go off" timer. OK, my apologies, I got turned around and had the earlier suggestion about a high-resolution poll still stuck in my head. You're absolutely right - no one is suggesting polling in the above. >> Am I missing something conceptually here? Why are people >> pushing for the single timer model? Is there some hidden >> complexity in a multi-timer approach that I'm not seeing? > > I implemented the single timer model yesterday, but I have to > admit, the reason was because I'm targeting GNUstep, and when I > stared at their source I discovered that they simply itterate > through *all* timers every run loop iteration checking if they've > gone off, their code also starts NSLogging warnings if you have > more than 1000 timers. I have no idea if apple's solution is > better than GNUstep's, but if it isn't, the single timer approach > would be vastly beneficial. Wow, I have to imagine there are a fair number of timers getting fired off throughout the system all the time for various tasks and that Apple would have optimized it more thoroughly. But a cursory inspection of the most recent open source CFRunLoop.c suggests that indeed is what is happening inside __CFRunLoopDoTimers. It's possible that I'm missing something in my tired state, but it sure does look like a simple loop. (There's a lot of magic happening in __CFRunLoopDoTimer, but it still gets called during each loop iteration.) Huh... color me surprised. Thanks for the response (and putting up with me). - -- Conrad Shultz Synthetiq Solutions www.synthetiqsolutions.com -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.14 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6Ff6wACgkQaOlrz5+0JdXnYwCeL8dCMMzWdLxigqgak56ADr9U jQUAnjltbDhavl2/PiwUiD7O+HofAU/Q =Yo8x -END PGP SIGNATURE- ___ 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
Re: Finder Integration
Damon, Firstly there is no official way to do this, all the solutions you see in the wild are hacks of one sort or another. Having said that, I had to implement what you are asking for (overlays on icons) and did it via SIMBL. Unfortunately I can't share code or say too much about what what is needed, but it would certainly help if you understood method swizzling and found a way to dump all the Obj_c classes that the Finder uses internally. Good luck Matt On 29 Sep 2011, at 20:39, Damon Allison wrote: > Hello, > > I am researching options for integrating with Finder. In particular, I would > like my application to provide file and directory icon overlays similar to > how Dropbox.app overlays green and blue images on top of file and folder > images. > > I noticed a few applications (svn utilities) that have used > `/Library/Contextual Menu Plugins` plugins to accomplish this. I've also seen > programs use SIMBL [1] plugins. Contextual Menu Plugins appears to have been > replaced by Automator Services, and SIMBL seems like an unsupported hack. > > Is there an 'official' way to integrate with the finder? If so, what is it? > If not, how does dropbox accomplish their finder integration? > > Either way, I would certainly appreciate any information / source code you > could provide. > > > Thanks, > Damon > > [1] SIMBL : > http://www.culater.net/software/SIMBL/SIMBL.php___ > ___ 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
Re: applicationWillFinishLaunching
I am not sure I get your first sentence right, but rather than relying on the
automatic delegate notification mechanism, you might want to actively subscribe
to the notification. You can do so from any object, not just a delegate.
[[NSNotificationCenter defaultCenter] addObserver:self
selector:@selector(finishInitialization)
name:NSApplicationWillFinishLaunchingNotification
object:NSApp];
If your app needs to do something at this stage which requires the existence
and activity of a run loop you could plug in a run loop observer once for the
first cycle of the run loop.
In something like your appController you implement a method and a function to
set things up:
void MyRunLoopObserver(CFRunLoopObserverRef observer,
CFRunLoopActivity activity,
void* info)
{
//replace MyAppController here by the name of the class of self
//refToSelf gives you access to everything (methods and ivars etc.) of self
//doSomething here is the method you want to call when the run loop starts
[(MyAppController *)refToSelf doSomething];
}
- (void) installRunLoopObserver
{
CFRunLoopObserverRef myObserver = NULL;
myObserver = CFRunLoopObserverCreate(NULL,
kCFRunLoopEntry,/* plug in at
the beginning of the run loop */
NO,/* do not repeat */
0,
&MyRunLoopObserver,
0);
if (myObserver)
{
// Now add it to the run loop
CFRunLoopAddObserver(CFRunLoopGetCurrent(),
myObserver,
kCFRunLoopCommonModes);
}
CFRelease(myObserver);
}
Then, in the same class, from somewhere early in the app launch process, e.g.
awakeFromNib, you set a global void * refToSelf (declared outside
@implementation)
refToSelf = self; //self, BTW, could be replaced by any object implementing the
doSomething method
and call
[self installRunLoopObserver]; //whereas self here, of course, is the object
calling installRunLoopObserver on itself
When the app enters the first run loop, doSomething is executed.
Note that the example in the documentation (of which the above is derived) does
not work as advertised. (I had consistent crashes when working with *info as a
container for self. Therefore I use the global refToSelf). This one works -
although I can not give you any guarantee that it will work out for your
special condition "plug into the first run loop cycle of the app", since I
haven't tried this special case. But since everything should be set up properly
at this point, it should work out.
Hope this helps.
Am 30.09.2011 um 01:48 schrieb koko:
> I have implemented applicationWillFinishLaunching in my app delegate but
> strangely (to me) it is not called but applicationDidFinishLaunching is
> called so I know my delegate is properly connected.
>
> Are there some conditions that must be met for
> applicationWillFinishLaunching to be called?
>
> What I want to do is ask for a serial number before the main window is
> displayed as the serial number will determine the app configuration and hence
> what appears in the main window. So, I thought I would ask for the serial
> number in applicationWillFinishLaunching thinking the main window will yet be
> visible. I would the configure the app.
>
> If there is a better way to accomplish this sequence of events I am all ears.
>
> -koko
>
> ___
>
> 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/magnard%40web.de
>
> This email sent to magn...@web.de
>
___
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
Re: creating multiple NSTimers
On 30 Sep 2011, at 08:19, Conrad Shultz wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 9/29/11 10:50 PM, Greg Guerin wrote: >> Gordon Apple wrote: >> >>> There must already be an array for the table, so just iterate >>> the >> array every >>> minute or whatever (single repeating timer), compare the times to >>> [NSDate date} and start or shut down whatever has not been >>> started or shut >> down. Much >>> easier than trying to manage timers. >> >> You don't have to iterate the whole array, either. Sort it by >> ascending order of turn-off time. Keep a current position (index). >> If the time of day is less than the turn-off time of the device at >> the current position, do nothing. If time of day >= turn-off time >> of current position, then turn it off and advance position until >> time of day is again less than the turn-off time of device at the >> current position. Only needs one timer, and scales to as large an >> array as you want to keep. > > I don't really see how this is superior to keeping the one timer per > remote box. > > When the user updates a timer, one is forced to re-sort the array and > reposition the index (under the above implementation). Why would you need to resort? Just remove, and reinsert. > One would also have to implement the scheme carefully, particularly if > the shut-off code is offloaded onto separate threads, to avoid > potential race conditions arising from a user changing a fire date in > the middle of a shut-off sequence. Careful locking required in multithreaded environment – unsurprising. > And as Graham mentioned, polling is probably less CPU and power > efficient than using timers anyway. Who's suggesting polling - you simply have one timer set for the time at which the first of your actual timers goes off. When it goes off, you fire the first of your actual timers, and reschedule your "when do other timers go off" timer. > Am I missing something conceptually here? Why are people pushing for > the single timer model? Is there some hidden complexity in a > multi-timer approach that I'm not seeing? I implemented the single timer model yesterday, but I have to admit, the reason was because I'm targeting GNUstep, and when I stared at their source I discovered that they simply itterate through *all* timers every run loop iteration checking if they've gone off, their code also starts NSLogging warnings if you have more than 1000 timers. I have no idea if apple's solution is better than GNUstep's, but if it isn't, the single timer approach would be vastly beneficial. Tom Davie___ 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
Re: creating multiple NSTimers
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 9/29/11 10:50 PM, Greg Guerin wrote: > Gordon Apple wrote: > >> There must already be an array for the table, so just iterate >> the > array every >> minute or whatever (single repeating timer), compare the times to >> [NSDate date} and start or shut down whatever has not been >> started or shut > down. Much >> easier than trying to manage timers. > > You don't have to iterate the whole array, either. Sort it by > ascending order of turn-off time. Keep a current position (index). > If the time of day is less than the turn-off time of the device at > the current position, do nothing. If time of day >= turn-off time > of current position, then turn it off and advance position until > time of day is again less than the turn-off time of device at the > current position. Only needs one timer, and scales to as large an > array as you want to keep. I don't really see how this is superior to keeping the one timer per remote box. When the user updates a timer, one is forced to re-sort the array and reposition the index (under the above implementation). One would also have to implement the scheme carefully, particularly if the shut-off code is offloaded onto separate threads, to avoid potential race conditions arising from a user changing a fire date in the middle of a shut-off sequence. And as Graham mentioned, polling is probably less CPU and power efficient than using timers anyway. Am I missing something conceptually here? Why are people pushing for the single timer model? Is there some hidden complexity in a multi-timer approach that I'm not seeing? - -- Conrad Shultz Synthetiq Solutions www.synthetiqsolutions.com -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.14 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6FbZoACgkQaOlrz5+0JdUAuQCcC3cpCXFJSa7/AMJcrca7l749 1zcAn1tM1yHYuZkoZhvCMPVdAA1UBX4u =tv8r -END PGP SIGNATURE- ___ 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
Re: Core Data : Undo Delete : Cannot fulfill a fault
On Sep 30, 2011, at 12:06 AM, Quincey Morris wrote: > The actual failure scenario I described has 2 necessary conditions. One is a > save boundary. The other is the flushing of cached property information for > the deleted object. The latter is difficult to cause, especially in a trivial > example, since there's no API for affecting the cache directly, except for > resetting the MOC, which would probably break undo for different reasons. > > I guess the question here is this: > > If it's true that deleting a managed object causes it to be turned into a > fault at some point (at the next save boundary at the latest), and saving a > managed context with a deleted object actually causes the object's persistent > representation to be deleted from the persistent store, and post-save the > object is still referenced by an undo action, what possible mechanism can > re-populate the object's properties if the undo action is undone? By > definition, the necessary information no longer exists. You are assuming that the only place this information can exist is in the row cache itself. The information can exist anywhere. At the risk of over-trivializing the problem—It’s just code™. All the information necessary to resurrect the object (or restore properties) can be stored on the undo stack itself. —Jim___ 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
Re: Core Data : Undo Delete : Cannot fulfill a fault
On Sep 29, 2011, at 22:52 , Jim Correia wrote: > Core Data’s undo stack does allow you to undo past the last save point. And > if it didn’t, it would remove actions from the undo manager, resulting in a > disabled undo menu, not leave a bunch of actions on the undo stack that would > generate exceptions if the user had the nerve to actually keep undoing past > the last save point. > >> If I'm right, you should be clearing the undo stack at a save, at least if >> there are deleted objects in the picture. > > If you in fact had to do this, this would be a pretty grievous bug. If the > MOC registers actions with its undo manager that it can no longer deal with, > it should be the one who removes them or clears the stack. "Should", yes. And perhaps what I've been suggesting is too outrageous for belief. However, there are a number of well-known examples of outrageousness. The most relevant one that I can think of is that NSPersistentDocument was originally released without (and may still not have, for all I know) support for NSDocument's "Save To…" behavior, as well as "Save As…" behavior that (apparently) went only as far as a successful default migration could carry it. In a different arena, there's the well known dangerousness of NSData under GC, and the fact that libSystem is marked as GC-compatible but isn't, not even nearly. It would be nice if every violation of the API contract were enforced, but it's not so. Sometimes, it's necessary to read the documentation and be self-policing. But I'd be more than happy to be shown wrong about this. :) > A trivial NSPersistentDocument sample application handles undo correctly > across save boundaries for both property changes and deletes. The actual failure scenario I described has 2 necessary conditions. One is a save boundary. The other is the flushing of cached property information for the deleted object. The latter is difficult to cause, especially in a trivial example, since there's no API for affecting the cache directly, except for resetting the MOC, which would probably break undo for different reasons. I guess the question here is this: If it's true that deleting a managed object causes it to be turned into a fault at some point (at the next save boundary at the latest), and saving a managed context with a deleted object actually causes the object's persistent representation to be deleted from the persistent store, and post-save the object is still referenced by an undo action, what possible mechanism can re-populate the object's properties if the undo action is undone? By definition, the necessary information no longer exists. ___ 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
