Re: (Problems) Scaling NSViews with scaleUnitSquareToSize
Oops. Didn't realize the photo album (image links) needed permissions changed. That should be fixed now. ___ 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
Initial Object in Array Controller
Hello, I've a simple application which for now just shows a tableview with a list of expenses ... NSArrayController (many of these are just the default...) Avoid Empty Selection - NO Preserve Selection - NO Select Inserted Objects - YES Clear Filter Predicate on Insert - YES Auto Rearrange Content - YES Always Use Multi Value Marker - NO Mode - Class ClassName - DJMExpense PreparesContent - YES Editable - YES No bindings configured in IB, but is connected to an outlet in MyDocument.m, and columns in the tableview are appropriately bound to the arrangedObjects.Name, etc as required. My understanding is that because of 'preparesContent=YES' it manages the array internally, which i get at with the [myController content]. This all works fine - I can add and remove new items via pushbuttons, view then in the TableView, etc. The only odd thing is that there is always a single, default item there when a new document is created. All my expense creations happen with +[DJMExpense expenseWithName:Amount] and if I place a breakpoint on -[DJMExpense init] I see the following backtrace: #0 -[DJMExpense init] (self=0x1001f41f0, _cmd=0x7fff9415b620) at /Users/davidm/Desktop/Code/test/test/DJMExpense.m:25 #1 0x7fff93da58db in -[NSObjectController newObject] () #2 0x7fff93da5833 in -[NSObjectController prepareContent] () #3 0x7fff91e549e1 in -[NSObject performSelector:] () #4 0x7fff91e54962 in -[NSSet makeObjectsPerformSelector:] () #5 0x7fff938e7c27 in -[NSIBObjectData nibInstantiateWithOwner:topLevelObjects:] () #6 0x7fff938de1b9 in loadNib () #7 0x7fff938dd6b6 in +[NSBundle(NSNibLoading) _loadNibFile:nameTable:withZone:ownerBundle:] () #8 0x7fff938dd5d1 in +[NSBundle(NSNibLoading) loadNibFile:externalNameTable:withZone:] () #9 0x7fff93acb328 in -[NSWindowController loadWindow] () #10 0x7fff93acb0e3 in -[NSWindowController window] () #11 0x7fff93b3ffb0 in -[NSDocument windowForSheet] () #12 0x7fff93acaa33 in -[NSDocument _shouldShowAutosaveButtonForWindow:] () #13 0x7fff93aca6e2 in -[NSWindowController setDocument:] () #14 0x7fff93c7ef4a in -[NSDocument makeWindowControllers] () #15 0x7fff93b3fda3 in -[NSDocument(NSPersistentUISupport) restoreDocumentWindowWithIdentifier:state:completionHandler:] () #16 0x7fff93b3fcf8 in -[NSDocumentControllerPersistentRestoration loadedDocument:forAutoID:] () #17 0x7fff93b3f80c in __-[NSDocumentController reopenDocumentForURL:withContentsOfURL:display:completionHandler:]_block_invoke_8 () #18 0x7fff93b2b558 in __-[NSDocumentController reopenDocumentForURL:withContentsOfURL:display:completionHandler:]_block_invoke_5 () #19 0x7fff93b2b4a3 in __-[NSDocumentController reopenDocumentForURL:withContentsOfURL:display:completionHandler:]_block_invoke_4 () #20 0x7fff93b2b1e5 in -[NSDocumentController _openDocumentWithContentsOfURL:usingProcedure:] () #21 0x7fff93b2add1 in __-[NSDocumentController reopenDocumentForURL:withContentsOfURL:display:completionHandler:]_block_invoke_3 () #22 0x7fff9141390a in _dispatch_call_block_and_release () #23 0x7fff9141577a in _dispatch_main_queue_callback_4CF () #24 0x7fff91df2c0c in __CFRunLoopRun () #25 0x7fff91df2216 in CFRunLoopRunSpecific () #26 0x7fff95afc4ff in RunCurrentEventLoopInMode () #27 0x7fff95b03c21 in ReceiveNextEventCommon () #28 0x7fff95b03aae in BlockUntilNextEventMatchingListInMode () #29 0x7fff938d6191 in _DPSNextEvent () #30 0x7fff938d5a95 in -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] () #31 0x7fff938d23d6 in -[NSApplication run] () #32 0x7fff93b5052a in NSApplicationMain () #33 0x00011492 in main (argc=2, argv=0x7fff5fbff968) at /Users/davidm/Desktop/Code/test/test/main.m:13 So apparently the NIB loading machinery is creating a new expense object and placing it into the ArrayController's content? Why would this be so? The object behaves just like any other, in that I can edit it in the tableview and/or remove via a button wired to [myArrayController remove:]. Ideally the array should be completely empty in a new document, and is up to the user's interaction to place the first object. What must I do to avoid this auto-creation of the object? Thanks, DavidM ps - please just let me know if I can share more details to help diagnose anything ... ___ 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: Initial Object in Array Controller
On Sep 29, 2011, at 02:42 , David Mirabito wrote: > My understanding is that because of 'preparesContent=YES' it manages the > array internally, which i get at with the [myController content]. Not quite so. Array controllers *always* manage a (separate) array, or an array property if configured via bindings. That's because it's a *controller*, while the array is a data model (respectively, the C and M of the MVC design pattern). The two things have different roles, so are always distinct. 'preparesContent=YES' is an option that tells the array controller that it is responsible for creating the data model. When specified with NSObjectController (NSArrayController's superclass), it creates an object of the class configured into the controller. When specified with NSArrayController, it creates an array for you, and (as you've seen) populates it with a single object of the configured class. > The only odd thing is that there is always a single, default item there when > a new document is created. > So apparently the NIB loading machinery is creating a new expense object and > placing it into the ArrayController's content? Why would this be so? The > object behaves just like any other, in that I can edit it in the tableview > and/or remove via a button wired to [myArrayController remove:]. > > Ideally the array should be completely empty in a new document, and is up to > the user's interaction to place the first object. What must I do to avoid > this auto-creation of the object? Just specify 'preparesContent=NO'. Unless you have an application where it would make sense for a new document to start off with a single generic array element (and I'm having trouble thinking of an example), you don't want or need this option to be set. There are a couple of cases where the option can *perhaps* be useful. One is with a NSObjectController, which by default gets a class of NSMutableDictionary in IB. That is, you can actually use an object controller to manage a collection of objects kept in a dictionary. (This is different from using a NSDictionaryController.) In that case, it might save you a step to have the controller create the content object (dictionary) for you. The other case is when the NSController (of any subclass) is in Entity mode for Core Data. In that case, the option causes a default fetch, and that might save you a slightly larger step that you'd otherwise have to code manually. In general, though, it's sort of easier to ignore the "preparesContent" option, and just take responsibility for creating the content object yourself. ___ 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
And another one... https://github.com/tcurdt/feedbackreporter cheers, Torsten ___ 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
Selecting UIButtons with code
I am missing something simple here. The following code doesn't work. I have
4 UIButtons, tagged 1,2,3,4
- (IBAction)clickedButton:(id)sender {
int tag = [sender tag];
for(int i=1;i<5;i++){
UIButton *button = (UIButton *)[self.view viewWithTag:tag];
if(i != tag){
[button setSelected:NO];
} else {
[button setSelected:YES];
}
}
...
What am I missing here?
___
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: Selecting UIButtons with code
You should probably change to:
UIButton *button = (UIButton *)[self.view viewWithTag:i];
("i" instead of "tag")
Regards
/John
29 sep 2011 kl. 14:52 skrev Eric E. Dolecki:
> I am missing something simple here. The following code doesn't work. I have
> 4 UIButtons, tagged 1,2,3,4
>
> - (IBAction)clickedButton:(id)sender {
>
>int tag = [sender tag];
>
>for(int i=1;i<5;i++){
>
>UIButton *button = (UIButton *)[self.view viewWithTag:tag];
>
>if(i != tag){
>
>[button setSelected:NO];
>
>} else {
>
>[button setSelected:YES];
>
>}
>
>}
>
> ...
>
>
> What am I missing here?
> ___
>
> 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/john_mlbox%40peekaboo.se
>
> This email sent to john_ml...@peekaboo.se
___
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 28, at 19:21, Dave Fernandes wrote: > I tried to reproduce this problem in my app and couldn't. I'm not surprised because it took me two years to find this corner case. After adding sufficient AppleScriptability to my app, I'm now able to reproduce it with a failure rate of about 59% vs. 0% by switching a #if. I'm slowly closing in on it. > I got these types of exceptions in the past when I was using KVO with my > managed objects, but I no longer do that. Thanks – I'll look for those. > I deleted a child object and saved the document. Then I performed an undo > operation, and the child and its component were both correctly brought back > to life (I could edit both of them), even though the component had never been > faulted in before the delete. So Core Data is saving their attributes > somewhere other than the persistent store. That's interesting that this occurs even if the object has never even been faulted in. Further confirmation of my conclusion, and yours, that Core Data is saving attributes elsewhere. I recall that the heavy lifter in a Core Data undo invocation seems to be -[NSManagedObjectContext _undoUpdates], which has no parameters. So, it's like NSManagedObjectContext has its own internal undo stack which, among other things, stashes the attributes of faulted objects, in case they need to be resurrected to fulfill an undo. In my corner case, at least one of those attributes are unavailable 59% of the time. If anyone knows any more about this mechanism, the info would be appreciated. ___ 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: Selecting UIButtons with code
Haha omg thanks :)
Sent from my iPhone
On Sep 29, 2011, at 9:03 AM, John Andersson wrote:
> You should probably change to:
>
> UIButton *button = (UIButton *)[self.view viewWithTag:i];
> ("i" instead of "tag")
>
> Regards
> /John
>
> 29 sep 2011 kl. 14:52 skrev Eric E. Dolecki:
>
>> I am missing something simple here. The following code doesn't work. I have
>> 4 UIButtons, tagged 1,2,3,4
>>
>> - (IBAction)clickedButton:(id)sender {
>>
>> int tag = [sender tag];
>>
>> for(int i=1;i<5;i++){
>>
>> UIButton *button = (UIButton *)[self.view viewWithTag:tag];
>>
>> if(i != tag){
>>
>> [button setSelected:NO];
>>
>> } else {
>>
>> [button setSelected:YES];
>>
>> }
>>
>> }
>>
>> ...
>>
>>
>> What am I missing here?
>> ___
>>
>> 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/john_mlbox%40peekaboo.se
>>
>> This email sent to john_ml...@peekaboo.se
>
___
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
NSDocument-oriented app and -keydown
how can I get a keydown (and keyup) events in an NSDocument-oriented application for a particular document's window? I'd like to get a control activated/deactivated on the window, depending on whether the specific key is pressed or released. I have found this: http://stackoverflow.com/questions/1526512/nsdocument-and-keyboard-like-keydown the answer that worked there was to use Carbon Shortcuts, but this does not let (as i understand) attach the event to the particular window-document, it is application wide. How can I receive such an event in an NSDocument's subclass? 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
Re: NSDocument-oriented app and -keydown
On Thu, Sep 29, 2011 at 7:42 AM, Nick wrote: > how can I get a keydown (and keyup) events in an NSDocument-oriented > application for a particular document's window? > I'd like to get a control activated/deactivated on the window, depending on > whether the specific key is pressed or released. Why does the document need key up and down events? These should almost always be handled in an NSView subclass. --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: Receiving Crash Reports
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. Thanks again! -koko On Sep 29, 2011, at 9:07 AM, Tito Ciuro wrote: > I would also consider plcrashreporter (iPhone and Mac OS X): > > http://code.google.com/p/plcrashreporter/ > > -- Tito > > On Sep 28, 2011, at 5:07 PM, koko wrote: > >> When a user of my app experiences a crash (arrggh) I would like intercept >> the Apple provided crash report window with the 'Send to Apple" button so I >> can have it sent to me. >> >> Is there a way to do this? >> >> -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/tciuro%40mac.com >> >> This email sent to tci...@mac.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: controller question
2011/9/28 Ariel Feinerman > I try to expline the problem. There is m_array (M) loaded from the file in > the one nib, then there is other two view controllers' nibs (C) with views > (V). One of them uses array controller to show and delete only, when the > other is used for insertion only throw dragging therefor no need in > controller. > sorry for repost, how to safely insert objects in m_array? > > 2011/9/28 Quincey Morris > >> On Sep 27, 2011, at 17:51 , Ariel Feinerman wrote: >> >> So in the case of insertion to m_array, we just have to reset content >> property: >> >> // somewhere in the code >> [self willChangeValueForKey: @"content"]; >> [m_array insertObject: url atIndex: 0]; >> [self didChangeValueForKey: @"content"]; >> >> // in the -observeValue... >> >> [controller setContent: m_array]; >> >> well? >> >> >> No, that's not it. I'm sorry I've confused the issue for you by saying >> something wrong earlier. >> >> Let's reset and start again. >> >> 1. You have an array (m_array) which you create and maybe populate in >> advance. This is the M in MVC. >> >> 2. You have an array controller (controller) which you create or maybe >> instantiate in a nib file. This is the C in MVC. >> >> 3. You have a view, for example a table view whose columns are bound to >> the array controller. This is the V in MVC. >> >> With this one-time line of code: >> >> [controller setContent: m_array]; >> >> you tell the array controller to *manage* m_array for you. There's no copy >> "inside" the array controller. That answers one of your questions. >> >> If you want to add or remove objects from m_array programmatically, then >> use the various [NSArrayController addObject…], [NSArrayController >> removeObject…], [NSArrayController insertObject…] methods. These method do >> two things: they *both* change the underlying array *and* tell the array >> controller that the underlying array changed. That answers another of your >> questions. >> >> So long as you use these methods, if you want to know what objects the >> array controller is managing, you can just look at m_array. That answers >> your last question. >> >> I understand these issues > > In this setup, KVO doesn't enter the picture, and I was wrong to say it >> did. >> >> That's basically the whole story, but I'll add two footnotes: >> >> -- If you need KVO notifications to be sent because *other* objects in >> your app need to be notified when things change, you should not use an array >> *object* (m_array), but rather an array *property* of some other object >> (such as a "myArray" property of your app delegate). In that case, you would >> likely bind the array controller to this array property, instead of using >> setContent, and everything can then be done KVO-compliantly. >> >> -- If there's no view involved here, there's really no good reason to be >> using an array controller at all. I don't think you mentioned a view, so I'm >> not sure what to assume. >> >> Is that clear? I think I've said it right now. >> >> >> completely ;-) > > > > -- > best regards > Ariel > -- best regards Ariel ___ 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-oriented app and -keydown
On 2011 Sep 29, at 07:42, Nick wrote: > but this does not let (as i understand) attach the event to the particular > window-document, it > is application wide. How can I receive such an event in an NSDocument's > subclass? I'm not sure what you mean by "attach the event", Nick, but the Mac has only one keyboard and therefore any determination of what modifier keys are down is going to be application-wide. You typically "receive" a keyDown (or other) event by overriding, say, -keyDown in any NSResponder subclass (view or window), and then use the Cocoa code given in the post by VassilisGr in that stackoverflow article to find what modifier keys are down. ___ 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)
The header documentation for -performSynchronousFileAccessUsingBlock: (which
also applies to performAsynchronousFileAccessUsingBlock:) says:
"this method's primary use is to wait for asynchronous saving, but in
contrast with that method it is only for use to wait for the part of an
asynchronous saving operation that actually touches the document's file or
values in memory that are in some way relative to the document's file."
and:
"In general you should use this method or
-performAsynchronousFileAccessUsingBlock: around code that gets or sets values
in memory that only make sense in the context of the document file's current
state."
In other words, these methods are used to prevent multiple operations from
operating simultaneously on the document's file and the file-related ivars. In
order to accomplish this, asynchronous saving must be implemented like so
(simplified, obviously):
performAsynchronousFileAccessUsingBlock:^(fileAccessCompletionHandler) {
dispatch_async(^{
write();
continueAsynchronousWorkOnMainThreadUsingBlock:^{
handle error, or update file ivars (fileURL,
fileModificationDate, fileType, change count, etc.)
fileAccessCompletionHandler();
}
})
}
waitForUserInteractionUnblocking()
If it were to call the fileAccessCompletionHandler any earlier then it might be
possible, for example, for -fileModificationDate to be invoked on the main
thread after -writeSafelyToURL: has written the file, but before the value has
been properly updated.
To address the example in your previous email, you want to do the latter
option, where you protect both -fileURL and the actual operation on the result
in a single call to -perform(A)synchronousFileAccessUsingBlock:. That is the
only way to ensure that something else within the process (or something in
another process using File Coordination) doesn't move the file out from under
you before you get to invoke -moveItemAtURL:toURL:error: or try to write to the
old URL before your move is complete, etc.
I don't see the nested uses of performSynchronousFileAccessUsingBlock: you
mentioned in that code, but that's not a problem anyway, since file access is
recursive, as long as it happens synchronously within the outer-most file
access block (a fact that admittedly may not be documented well anywhere).
-KP
On Sep 28, 2011, at 11:23 PM, Kyle Sluder wrote:
> On Wed, Sep 28, 2011 at 10:55 PM, Kyle Sluder wrote:
>> I'd really appreciate if the documentation spelled out exactly how
>> NSDocument uses these methods.
>
> To give an example of a specific NSDocument usage that I'd like to
> know about: how does asynchronous saving use
> -performAsynchronousFileAccessUsingBlock:? I'm envisioning something
> like this:
>
> - (void)saveToURL:(NSURL *)url ofType:(NSString *)type
> forSaveOperation:(NSSaveOperation)op completionHandler:(void
> (^)(NSError *errorOrNil))completionHandler {
> id saveToken = [self changeCountTokenForSaveOperation:op];
>
> if ([self canAsynchronouslyWriteToURL:url ofType:type forSaveOperation:op]) {
>[self performAsynchronousFileAccessUsingBlock:(void
> (^fileAccessCompletionHandler)(void)) {
> dispatch_async(backgroundQueue, ^{
>NSError *error;
>BOOL success;
>success = [self writeSafelyToURL:url ofType:type
> forSaveOperation:op error:&error];
>
>fileAccessCompletionHandler();
>
>if (success)
> [self continueAsynchronousWorkOnMainThreadUsingBlock:^{
>[self setFileURL:url];
>[self setFileModificationDate:[NSDate date]];
>[self setFileType:type];
>[self setAutosavedContentsFileURL:url];
>[self updateChangeCountWithToken:token forSaveOperation:op];
>completionHandler(nil);
> }];
>else
> [self continueAsynchronousWorkOnMainThreadUsingBlock:^{
>completionHandler(error);
> }];
>});
>
>WaitForUnblockUserInteraction();
> }];
>}
> }
>
> Am I on the right track here?
>
> --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/kperry%40apple.com
>
> This email sent to kpe...@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-ar
Re: NSDocument-oriented app and -keydown
On Thu, Sep 29, 2011 at 8:30 AM, Jerry Krinock wrote: > > On 2011 Sep 29, at 07:42, Nick wrote: > >> but this does not let (as i understand) attach the event to the particular >> window-document, it >> is application wide. How can I receive such an event in an NSDocument's >> subclass? > > I'm not sure what you mean by "attach the event", Nick, but the Mac has only > one keyboard and therefore any determination of what modifier keys are down > is going to be application-wide. Actually not so, as I discovered yesterday. I have two keyboards attached to my Mac. Holding Cmd on one and pressing "A" on the other does *not* result in a Cmd-A being sent to the app. Modifier keys are attached to the keyboard they came from. In my scenario, you get a "flagsChanged" event for the Cmd key and a regular keyDown event for the A key. --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
Cleaning up a window with blocks
The intent of the following code is to implement a quick and easy way to bring
up a window and provide a way to clean up after it closes. The problem is that
it is crashing. I believe I am missing something obvious here and was hoping
that someone could remove the blinders...
- (void) displayWindow
{
NSURL* documentURL;
NSWindowController* controller;
id theObserver;
documentURL = [[NSBundle mainBundle] URLForResource:@"document"
withExtension:@"rtf"];
controller = [[NSWindowController alloc]
initWithWindowNibName:@"DocDisplay"];
theObserver = [[NSNotificationCenter defaultCenter]
addObserverForName:NSWindowWillCloseNotification
object:[controller window]
queue:nil
usingBlock:^(NSNotification *note)
{
[[NSNotificationCenter defaultCenter]
removeObserver:theObserver];
[[controller window] orderOut:self];
[controller autorelease];
}];
NSArray*subviews= [[[controller window] contentView] subviews];
NSScrollView* scrollView = [subviews objectAtIndex:0];
NSTextView* rtfView = [scrollView documentView];
[rtfView readRTFDFromFile:[documentURL path]];
[[controller window] setTitle:@"TheTitle"];
[[controller window] makeKeyAndOrderFront:self];
}
Here's the relevant part of the crash log:
0 libobjc.A.dylib objc_msgSend_vtable13 + 13
1 libobjc.A.dylib objc_retain + 19
2 libsystem_blocks.dylib_Block_object_assign + 336
3 com.company.app __copy_helper_block_ + 67
4 libsystem_blocks.dylib_Block_copy_internal + 203
5 com.apple.CoreFoundation -[NSBlock copy] + 39
6 com.apple.Foundation +[__NSObserver
observerWithCenter:queue:name:object:block:] + 211
7 com.apple.Foundation -[NSNotificationCenter
addObserverForName:object:queue:usingBlock:] + 134
8 com.company.app -[TMBrowserAppDelegate displayWindow:] + 494
___
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: Cleaning up a window with blocks
A quick scan over the code says that your issue is that you're referring to
theObserver inside theObserver, which, when the block is constructed, as not
yet been assigned the result of addObserverForName:...
Bob
if (*ra4 != 0xffc78948) { return false; }
On 29 Sep 2011, at 17:37, Eric Gorr wrote:
> The intent of the following code is to implement a quick and easy way to
> bring up a window and provide a way to clean up after it closes. The problem
> is that it is crashing. I believe I am missing something obvious here and was
> hoping that someone could remove the blinders...
>
>
> - (void) displayWindow
> {
> NSURL* documentURL;
> NSWindowController* controller;
> id theObserver;
>
> documentURL = [[NSBundle mainBundle] URLForResource:@"document"
> withExtension:@"rtf"];
> controller = [[NSWindowController alloc]
> initWithWindowNibName:@"DocDisplay"];
>
> theObserver = [[NSNotificationCenter defaultCenter]
> addObserverForName:NSWindowWillCloseNotification
>
> object:[controller window]
>queue:nil
>
> usingBlock:^(NSNotification *note)
> {
> [[NSNotificationCenter defaultCenter]
> removeObserver:theObserver];
>
> [[controller window] orderOut:self];
> [controller autorelease];
> }];
>
> NSArray*subviews= [[[controller window] contentView] subviews];
> NSScrollView* scrollView = [subviews objectAtIndex:0];
> NSTextView* rtfView = [scrollView documentView];
>
> [rtfView readRTFDFromFile:[documentURL path]];
>
> [[controller window] setTitle:@"TheTitle"];
>
> [[controller window] makeKeyAndOrderFront:self];
> }
>
>
> Here's the relevant part of the crash log:
>
>
> 0 libobjc.A.dylib objc_msgSend_vtable13 + 13
> 1 libobjc.A.dylib objc_retain + 19
> 2 libsystem_blocks.dylib_Block_object_assign + 336
> 3 com.company.app __copy_helper_block_ + 67
> 4 libsystem_blocks.dylib_Block_copy_internal + 203
> 5 com.apple.CoreFoundation -[NSBlock copy] + 39
> 6 com.apple.Foundation +[__NSObserver
> observerWithCenter:queue:name:object:block:] + 211
> 7 com.apple.Foundation -[NSNotificationCenter
> addObserverForName:object:queue:usingBlock:] + 134
> 8 com.company.app -[TMBrowserAppDelegate displayWindow:] + 494
>
>
>
> ___
>
> 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/tom.davie%40gmail.com
>
> This email sent to tom.da...@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: controller question
On Sep 29, 2011, at 08:20 , Ariel Feinerman wrote: >> 2011/9/28 Ariel Feinerman: >> >> I try to expline the problem. There is m_array (M) loaded from the file in >> the one nib, then there is other two view controllers' nibs (C) with views >> (V). One of them uses array controller to show and delete only, when the >> other is used for insertion only throw dragging therefor no need in >> controller. > > sorry for repost, how to safely insert objects in m_array? > >> 2011/9/28 Quincey Morris: >> >> If you want to add or remove objects from m_array programmatically, then use >> the various [NSArrayController addObject…], [NSArrayController >> removeObject…], [NSArrayController insertObject…] methods. ___ 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-oriented app and -keydown
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
Re: NSDocument-oriented app and -keydown
On Sep 29, 2011, at 8:42 AM, Nick wrote: > how can I get a keydown (and keyup) events in an NSDocument-oriented > application for a particular document's window? > I'd like to get a control activated/deactivated on the window, depending on > whether the specific key is pressed or released. Key events are passed along the responder chain. The document window delegate is in the responder chain and will respond to -keyDown:, -keyUp:, and -flagsChanged: events. You could subclass NSWindowController and make it the delegate of your document window and handle the events there. NSWindowController Class Reference documentation has a nice paragraph on subclassing. http://developer.apple.com/library/mac/#documentation/Cocoa/Reference/ApplicationKit/Classes/NSWindowController_Class/Reference/Reference.html Document-Based Applications Overview documentation also has a section on "Should I subclass NSWindowController?" http://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/Documents/Tasks/FAQ.html#//apple_ref/doc/uid/2954-1080900 If you need custom handling of modifier keys at the application level or absolutely need all key up events you could subclass NSApplication and override the -sendEvent: method. --Richard ___ 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 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. -- Sean McBride, B. Eng s...@rogue-research.com Rogue Researchwww.rogue-research.com Mac Software Developer Montréal, Québec, Canada ___ 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 06:22 , Jerry Krinock wrote: > That's interesting that this occurs even if the object has never even been > faulted in. Further confirmation of my conclusion, and yours, that Core > Data is saving attributes elsewhere. I recall that the heavy lifter in a > Core Data undo invocation seems to be -[NSManagedObjectContext _undoUpdates], > which has no parameters. So, it's like NSManagedObjectContext has its own > internal undo stack which, among other things, stashes the attributes of > faulted objects, in case they need to be resurrected to fulfill an undo. In > my corner case, at least one of those attributes are unavailable 59% of the > time. > > If anyone knows any more about this mechanism, the info would be appreciated. I think the answer to your original question is that You're Doing It Wrong™. :) I'm pretty sure (though I never really thought about it before today) that Core Data undo *doesn't* work across 'save:' boundaries. The documentation for [NSManagedObjectContext undo:] says this: > "Sends an undo message to the receiver’s undo manager, asking it to reverse > the latest uncommitted changes applied to objects in the object graph." Note that word "uncommitted". After 'save:', all changes are committed, so you're not permitted to undo past that point. At least, that's how I read it. I think I can also advance an explanation why it works part of the time. This is based on my Core Data entrail-readings from Leopard days, so it's only guesswork, and things may have changed since then. Take this with a grain of salt. Core Data accesses property data at least 3 levels: (#1) what's in the persistent store (i.e. on disk); (#2) what pointed to by fault-fulfilled objects (i.e. value objects in memory); (#3) an internal cache of property data previous read from the store. This last is not tied to the existence of any particular object, it's just a historical cache. If you delete an object (thereby allowing its property values to be flushed from memory), then try to undo the deletion, the object may not be able to be restored to its original state from #2, because those value objects have been released. If you've *also* done a 'save:' after the deletion but before the undo, that's certainly the case, plus the object can't be restored to its original state from #1, because it doesn't exist there any more. However, the object *can* (apparently, I'm guessing) be restored from #3 *if* its properties happen to still be in the cache. In many, many cases of undoing fairly soon after the deletion (perhaps 41% of the time in your testing scenario), the property data will still be available. The rest of the time, well, you'll suck a big fulfillment failure. If I'm right, you should be clearing the undo stack at a save, at least if there are deleted objects in the picture. Alternately, I'm completely wrong. ___ 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 Thu, Sep 29, 2011 at 9:20 AM, Kevin Perry wrote:
> If it were to call the fileAccessCompletionHandler any earlier then it might
> be possible, for example, for -fileModificationDate to be invoked on the
> main thread after -writeSafelyToURL: has written the file, but before the
> value has been properly updated.
Thank you, this is enlightening. Your sketch omitted the "take a
snapshot of the document wrapper" part; I assume that comes prior to
the call to -performAsynchronousFileAccess…, but still within the same
enveloping call to -performActivityWithSynchronousWaiting:….
However, I am still concerned about blocking other apps. According to
the documentation, -performAsynchronousFileAccessUsingBlock: does not
block the main thread. But it surely has to block _something_ until
the fileAccessCompletionHandler is called. We've guaranteed that we've
escaped the -performAsynchronousFileAccess stack frame by calling
dispatch_async(). Is it just blocking other NSFileCoordinator requests
until the fileAccessCompletionHandler is called? In that case, why is
the fileAccessCompletionHandler important for synchronizing with our
own main thread access, and how can it possibly protect our calls to
-fileURL from within the block passed to dispatch_async? Does
"-performAsynchronousFileAccess does not block the main thread" really
mean "if I can't execute the block now, I will execute it later, and
in doing so the thread on which this method was called (which might be
the main thread) will be blocked until the block has finished
executing _and_ the fileAccessCompletionHandler has been called"?
In my original example, I was using -performSynchronousFileAccess
around my call to -moveItemAtURL:toURL:error: and the subsequent call
to -presentError:, rather than -performAsynchronousFileAccess. If
-presentError: throws up an app-modal alert, then I've blocked any
other pending NSFileCoordinator clients who want to access my file,
correct? This can include other file presenters in my own app, who
might perhaps want to read the document in the background?
Or do I need to switch to -performAsynchronousFileAccess to make sure
I don't cause other apps to beachball? If so, would it look roughly
like this?
/**
* Again, not meant to be a good example of using NSFileManager.
**/
- (BOOL)isInHomeDirectory {
NSURL *fileURL = [self fileURL];
return [[fileURL absoluteString] hasPrefix:NSHomeDirectory()];
}
- (IBAction)doThing:(id)sender {
[self performActivityWithSynchronousWaiting:YES usingBlock:^{
[self performAsynchronousFileAccessUsingBlock:^(void
(^fileAccessCompletionHandler)(void){
dispatch_async(backgroundQueue, ^{
BOOL isInHome = [self isInHomeDirectory];
if (isInHome) {
NSURL *fileURL = [self fileURL];
NSURL destinationURL = [NSURL
fileURLWithPath:[NSTemporaryDirectory()
stringByAppendingPathComponent:[fileURL lastPathComponent]]];
NSError *error;
BOOL success = [[NSFileManager defaultManager]
moveItemAtURL:fileURL toURL:destinationURL error:&error];
[self continueAsynchronousWorkOnMainThreadUsingBlock:^{
fileAccessCompletionHandler();
if (!success)
[self presentError:error];
}];
}
});
}];
}];
}
All -performActivityWithSynchronousWaiting:usingBlock: is doing here
is wrapping a call to -performAsynchronousFileAccessUsingBlock:, which
in turn is just wrapping a call to dispatch_async. Do I need to
reimplement my own analogue to -unblockUserInteraction, to ensure the
user doesn't make any changes to the document while the move operation
is taking place on my backgroundQueue? Or is that scenario specific to
the conflict between "save the document asynchronously" vs "manipulate
the document's data?"
Sorry to bombard you with questions, but the headerdoc only goes so far.
--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: NSDocument Serialization (-performSynchronousFileAccessUsingBlock: and friends)
On Sep 29, 2011, at 12:00 PM, Kyle Sluder wrote:
> On Thu, Sep 29, 2011 at 9:20 AM, Kevin Perry wrote:
>> If it were to call the fileAccessCompletionHandler any earlier then it might
>> be possible, for example, for -fileModificationDate to be invoked on the
>> main thread after -writeSafelyToURL: has written the file, but before the
>> value has been properly updated.
>
> Thank you, this is enlightening. Your sketch omitted the "take a
> snapshot of the document wrapper" part; I assume that comes prior to
> the call to -performAsynchronousFileAccess…, but still within the same
> enveloping call to -performActivityWithSynchronousWaiting:….
For Versions, you mean? That also happens within
-performAsynchronousFileAccess:, because we don't want anything else touching
the file while we're preserving the version.
> However, I am still concerned about blocking other apps. According to
> the documentation, -performAsynchronousFileAccessUsingBlock: does not
> block the main thread. But it surely has to block _something_ until
> the fileAccessCompletionHandler is called.
Yeah, it blocks further invocations of
-perform(A)synchronousFileAccessUsingBlock:, where "block" means "enqueue" for
async access, and "block the thread" for sync access.
> We've guaranteed that we've
> escaped the -performAsynchronousFileAccess stack frame by calling
> dispatch_async(). Is it just blocking other NSFileCoordinator requests
> until the fileAccessCompletionHandler is called?
NSDocument's NSFilePresenter methods use
performAsynchronousFileAccessUsingBlock: internally, so if something else
current has file access, the NSFileCoordinator requests are indeed blocked (or
"enqueued").
> In that case, why is
> the fileAccessCompletionHandler important for synchronizing with our
> own main thread access, and how can it possibly protect our calls to
> -fileURL from within the block passed to dispatch_async?
With async file access, you have sole access to the file until you call
fileAccessCompletionHandler, even if you move out of the original block's
execution with dispatch_async, etc. For example, if you have these two methods:
doSync:
performSyncFileAccess:{
[self setFileURL:]
}
doAsync:
performAsyncFileAccess:^{
dispatch_async(^{
[self fileURL]
fileAccessCompletionHandler()
})
}
and you call them like this:
[self doAsync]
[self doSync]
The [self fileURL] call in doAsync is safe, because doSync's
performSyncFileAccess: won't run doAsync's fileAccessCompletionHandler() is
called.
Similarly, if you have this additional method:
doAsync2:
performAsyncFileAccess:^{
[self setFileURL:]
}
and call them like this:
[self doAsync]
[self doAsync2]
This is also safe because doAsync2's block won't be invoked until doAsync's
fileAccessCompletionHandler() is called.
> Does
> "-performAsynchronousFileAccess does not block the main thread" really
> mean "if I can't execute the block now, I will execute it later, and
> in doing so the thread on which this method was called (which might be
> the main thread) will be blocked until the block has finished
> executing _and_ the fileAccessCompletionHandler has been called"?
No, because blocking the thread until fileAccessCompletionHandler is called
would defeat the purpose of asynchronous saving. The thread is unblocked
immediately after the block finishes executing. The main thread will only be
blocked if performSynchronousFileAccess: is called later and the async file
access hasn't yet completed.
> In my original example, I was using -performSynchronousFileAccess
> around my call to -moveItemAtURL:toURL:error: and the subsequent call
> to -presentError:, rather than -performAsynchronousFileAccess. If
> -presentError: throws up an app-modal alert, then I've blocked any
> other pending NSFileCoordinator clients who want to access my file,
> correct? This can include other file presenters in my own app, who
> might perhaps want to read the document in the background?
There should be no need to include error presentation with the file access.
Sorry I missed that in the original example. The usual pattern is:
performAsyncFileAccess:^{
NSError *error;
doSomethingWithFile(&error);
fileAccessCompletionHandler();
handleError(error);
}
or:
__block NSError *error;
performSyncFileAccess:^{
doSomethingWithFile(&error);
}
handleError(error);
> Or do I need to switch to -performAsynchronousFileAccess to make sure
> I don't cause other apps to beachball? If so, would it look roughly
> like this?
>
> /**
> * Again, not meant to be a good example of using NSFileManager.
> **/
>
> - (BOOL)isInHomeDirectory {
> NSURL *fileURL = [self fileURL];
> return [[fileURL absoluteString] hasPrefix:NSHomeDirectory()];
> }
>
> - (IBAction)doThing:(id)sender {
> [self performActivityWithSynchronous
Re: Cleaning up a window with blocks
On Sep 29, 2011, at 11:42 AM, Thomas Davie wrote: > A quick scan over the code says that your issue is that you're referring to > theObserver inside theObserver, which, when the block is constructed, as not > yet been assigned the result of addObserverForName:... You can fix that by declaring theObserver with the __block qualifier. Cheers, Ken ___ 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: Cleaning up a window with blocks
Ya, thanks. I spotted that almost immediately after I posted the message. On Sep 29, 2011, at 4:22 PM, Ken Thomases wrote: > On Sep 29, 2011, at 11:42 AM, Thomas Davie wrote: > >> A quick scan over the code says that your issue is that you're referring to >> theObserver inside theObserver, which, when the block is constructed, as not >> yet been assigned the result of addObserverForName:... > > You can fix that by declaring theObserver with the __block qualifier. > > Cheers, > Ken > ___ 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
Question about SMJobBless
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
creating multiple NSTimers
For the life of me I cannot figure this one out. I need to create an indeterminate amount of timers for an app I am working on. The app is petty simple. For example, provide a list of ip enabled devices with times to shut off and the app executes the device's shutdown at the specified time. I need to retain a reference to each timer so that I can invalidate the timer if necessary. Obviously setting up one timer or two timers is not a problem. NSTimer *myTimer1; NSTimer *myTimer2; etc. However, I do not know wether the user will have 1 device or 100 devices. Do I have to setup a finite amount of timers (ultimately having a limit on the number of devices that can be added) or is there a better way? I have googled for a while now trying to find example code but have come up empty (plenty of finite examples). I see there are timer applications out there that seem to handle an infinite number of timers. Thanks Tom___ 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
Can't you use a loop and then stuff the timers into an NSMutableArray or NSMutableDictionary to access? On Thu, Sep 29, 2011 at 5:47 PM, Tom Hohensee wrote: > For the life of me I cannot figure this one out. I need to create an > indeterminate amount of timers for an app I am working on. The app is petty > simple. For example, provide a list of ip enabled devices with times to > shut off and the app executes the device's shutdown at the specified time. > I need to retain a reference to each timer so that I can invalidate the > timer if necessary. Obviously setting up one timer or two timers is not a > problem. > > NSTimer *myTimer1; > NSTimer *myTimer2; > etc. > > However, I do not know wether the user will have 1 device or 100 devices. > Do I have to setup a finite amount of timers (ultimately having a limit on > the number of devices that can be added) or is there a better way? I have > googled for a while now trying to find example code but have come up empty > (plenty of finite examples). I see there are timer applications out there > that seem to handle an infinite number of timers. > > Thanks > Tom___ > > 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/edolecki%40gmail.com > > This email sent to edole...@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
On Sep 29, 2011, at 2:47 PM, Tom Hohensee wrote: > However, I do not know wether the user will have 1 device or 100 devices. Do > I have to setup a finite amount of timers (ultimately having a limit on the > number of devices that can be added) or is there a better way? I have > googled for a while now trying to find example code but have come up empty > (plenty of finite examples). I see there are timer applications out there > that seem to handle an infinite number of timers. Have you looked into NSMutableArray? -- David Duncan ___ 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 29, at 11:20, Quincey Morris wrote: > I'm pretty sure (though I never really thought about it before today) that > Core Data undo *doesn't* work across 'save:' boundaries. The documentation > for [NSManagedObjectContext undo:]… > If I'm right, you should be clearing the undo stack at a save, at least if > there are deleted objects in the picture. My jaw has been on the floor for the last half hour. I removed the 'save' line from my AppleScript, and my corner case executed 36 times with no trouble. I think you might be correct. This has huge implications. I shall explain after further study. ___ 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
Yes. What I have worked on is using an array of timers fired sequentially. Each firing of the timer sets up the next one in the array. Each new addition to the array requires invalidating of the active timer and reordering of the array according to times. But i have run into problems when two or more timers are set to fire at the same time. Tom On Sep 29, 2011, at 4:51 PM, David Duncan wrote: > On Sep 29, 2011, at 2:47 PM, Tom Hohensee wrote: > >> However, I do not know wether the user will have 1 device or 100 devices. >> Do I have to setup a finite amount of timers (ultimately having a limit on >> the number of devices that can be added) or is there a better way? I have >> googled for a while now trying to find example code but have come up empty >> (plenty of finite examples). I see there are timer applications out there >> that seem to handle an infinite number of timers. > > > Have you looked into NSMutableArray? > -- > David Duncan > > ___ > > 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/tomhoh%40mac.com > > This email sent to tom...@mac.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: Selecting UIButtons with code
This line,
>UIButton *button = (UIButton *)[self.view viewWithTag:tag];
is returning something that is not a UIButton, and it won't respond to
setSelected.
On Sep 29, 2011, at 5:52 AM, Eric E. Dolecki wrote:
> I am missing something simple here. The following code doesn't work. I have
> 4 UIButtons, tagged 1,2,3,4
>
> - (IBAction)clickedButton:(id)sender {
>
>int tag = [sender tag];
>
>for(int i=1;i<5;i++){
>
>UIButton *button = (UIButton *)[self.view viewWithTag:tag];
>
>if(i != tag){
>
>[button setSelected:NO];
>
>} else {
>
>[button setSelected:YES];
>
>}
>
>}
>
> ...
>
>
> What am I missing here?
> ___
>
> 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/rowlandd%40sbcglobal.net
>
> This email sent to rowla...@sbcglobal.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: creating multiple NSTimers
I think you need to backup and explain exactly what your requirements are. If you really do need to track these timers, you will probably need an array or dictionary, but if these timers are all one-shot and they configure the next timer to execute, there seems little reason to maintain your own owning reference to them... On Sep 29, 2011, at 3:06 PM, Tom Hohensee wrote: > Yes. What I have worked on is using an array of timers fired sequentially. > Each firing of the timer sets up the next one in the array. Each new > addition to the array requires invalidating of the active timer and > reordering of the array according to times. But i have run into problems > when two or more timers are set to fire at the same time. > > Tom > > On Sep 29, 2011, at 4:51 PM, David Duncan wrote: > >> On Sep 29, 2011, at 2:47 PM, Tom Hohensee wrote: >> >>> However, I do not know wether the user will have 1 device or 100 devices. >>> Do I have to setup a finite amount of timers (ultimately having a limit on >>> the number of devices that can be added) or is there a better way? I have >>> googled for a while now trying to find example code but have come up empty >>> (plenty of finite examples). I see there are timer applications out there >>> that seem to handle an infinite number of timers. >> >> >> Have you looked into NSMutableArray? >> -- >> David Duncan >> >> ___ >> >> 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/tomhoh%40mac.com >> >> This email sent to tom...@mac.com > -- David Duncan ___ 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: Selecting UIButtons with code
I had a brain fart. That line DID return a UIButton, but only when the tag
matched i :)
Google Voice: (508) 656-0622
Twitter: eric_dolecki XBoxLive: edolecki PSN: eric_dolecki
http://blog.ericd.net
On Thu, Sep 29, 2011 at 6:14 PM, David Rowland wrote:
> This line,
>
> >UIButton *button = (UIButton *)[self.view viewWithTag:tag];
>
> is returning something that is not a UIButton, and it won't respond to
> setSelected.
>
>
>
> On Sep 29, 2011, at 5:52 AM, Eric E. Dolecki wrote:
>
> > I am missing something simple here. The following code doesn't work. I
> have
> > 4 UIButtons, tagged 1,2,3,4
> >
> > - (IBAction)clickedButton:(id)sender {
> >
> >int tag = [sender tag];
> >
> >for(int i=1;i<5;i++){
> >
> >UIButton *button = (UIButton *)[self.view viewWithTag:tag];
> >
> >if(i != tag){
> >
> >[button setSelected:NO];
> >
> >} else {
> >
> >[button setSelected:YES];
> >
> >}
> >
> >}
> >
> > ...
> >
> >
> > What am I missing here?
> > ___
> >
> > 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/rowlandd%40sbcglobal.net
> >
> > This email sent to rowla...@sbcglobal.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: creating multiple NSTimers
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 9/29/11 3:06 PM, Tom Hohensee wrote: > Yes. What I have worked on is using an array of timers fired > sequentially. Each firing of the timer sets up the next one in the > array. Each new addition to the array requires invalidating of the > active timer and reordering of the array according to times. But i > have run into problems when two or more timers are set to fire at > the same time. I don't really follow what you are doing here, but given the original description of your problem, wouldn't an NSMutableDictionary keyed by IP be a good choice? Then you can just add/remove timers as needed and not have to worry about shifting an array. If you are trying to get the timers ordered by when they will fire, do not overlook, e.g., NSDictionary's –keysSortedByValueUsingComparator:. - -- Conrad Shultz Synthetiq Solutions www.synthetiqsolutions.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFOhO6raOlrz5+0JdURAoLMAJ4qJwuj5/6riE4jhtc3n6mafOYxdACbBOJP yUKa53Va5NYPgITcnpJJyPU= =xa6z -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: creating multiple NSTimers
On Sep 29, 2011, at 3:06 PM, Tom Hohensee wrote: > Yes. What I have worked on is using an array of timers fired sequentially. > Each firing of the timer sets up the next one in the array. Each new > addition to the array requires invalidating of the active timer and > reordering of the array according to times. But i have run into problems > when two or more timers are set to fire at the same time. What you’re describing sounds like the work that the runloop performs internally to manage multiple active timers. Why not let the runloop do the work for you? Just start up all the timers in parallel and wait for them to fire. —Jens___ 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
Hi Tom-
Could you use a single, repeating timer with sufficient resolution for your
purposes and an array or dictionary storing the needed timing state? Then
update state appropriately at each fire of the single timer?
Array {
Timing Item 1 {
currentTime: 24.2
running: YES
expires: 60.0
}
Timing Item 2 {
… etc.
}
}
- (void)doSomething:(NSTimer *)timer
{
// increment timing state
// expire overdue items
// etc.
}
Not sure of what you're trying to accomplish; perhaps this a different way to
consider the issue. HTH!
John
John Pannell
http://www.positivespinmedia.com
On Sep 29, 2011, at 4:06 PM, Tom Hohensee wrote:
> Yes. What I have worked on is using an array of timers fired sequentially.
> Each firing of the timer sets up the next one in the array. Each new
> addition to the array requires invalidating of the active timer and
> reordering of the array according to times. But i have run into problems
> when two or more timers are set to fire at the same time.
>
> Tom
___
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
delegate of an NWindowController's window
I'm trying to get the delegate of a window that is controlled by a custom NSWindowController as follows: NSWindow *win = [self window]; id del = [win delegate]; But get the following warning: warning: Semantic Issue: Initializing 'id' with an expression of incompatible type 'id' What am I doing wrong? Thanks, - Koen. ___ 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: delegate of an NWindowController's window
The NSWindow delegate's type is id not id . This is the compiler telling you the types don't match. Sent from my iPhone On Sep 29, 2011, at 6:22 PM, Koen van der Drift wrote: > I'm trying to get the delegate of a window that is controlled by a custom > NSWindowController as follows: > > NSWindow *win = [self window]; > id del = [win delegate]; > > But get the following warning: > > warning: Semantic Issue: Initializing 'id' with an > expression of incompatible type 'id' > > What am I doing wrong? > > Thanks, > > - Koen. > > ___ > > 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/jamiepinkham%40me.com > > This email sent to jamiepink...@me.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: delegate of an NWindowController's window
On Sep 29, 2011, at 5:38 PM, Jamie Pinkham wrote: > On Sep 29, 2011, at 6:22 PM, Koen van der Drift > wrote: > >> I'm trying to get the delegate of a window that is controlled by a custom >> NSWindowController as follows: >> >> NSWindow *win = [self window]; >> id del = [win delegate]; >> >> But get the following warning: >> >> warning: Semantic Issue: Initializing 'id' with an >> expression of incompatible type 'id' >> >> What am I doing wrong? > > The NSWindow delegate's type is id not id > . This is the compiler telling you the types don't > match. In particular, "id " is an id (a pointer to an object of indeterminate type) which is known to conform to a _protocol_ called "whatever". I think you have confused NSWindowDelegate for some arbitrary placeholder, perhaps for a class name. If your delegate class is call MyControllerDelegate, then you want: MyControllerDelegate* del = [win delegate]; And the definition of MyControllerDelegate should have declared its conformance to the NSWindowDelegate protocol. Regards, Ken ___ 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: Numeric Entry and Formatting With NSNumberFormatter Won't Append Zeros
> > I suspect you're halfway to the solution. When you get a partially-entered > string, you are already looking for the decimal point (which should of course > be a localized comparison). You *could* try to insert the grouping separators > yourself, but that would potentially involve writing a formatter for every > localized display format, so that's not a great approach. Alternately, you > could take the substring *before* the decimal point and run that through a > regular string/numeric/string conversion to get the group separators in > place. (If there's a decimal point, you know that what's before it is a > *complete* whole number.) Then re-combine that with the original > post-decimal-point substring -- with the trailing "0" characters intact. > > Such an approach involves only two assumptions I can think of: > > 1. It's always possible to recognize a decimal point if present, and divide > the string there, so that the initial portion is a well-formed (whole) number. > > 2. The rules for inserting grouping separators don't depend on what comes > after the decimal point, if present. > > Those assumptions don't sound too bad to me. > I am now doing what I believe is essentially what you suggest. I test for a decimal point, and if there isn't one, I let the formatter do its thing and it applies the grouping separators just fine. If a decimal point is detected I no longer call the formatter and I let the string be appended after the decimal point with no further formatting. It's working so far. > On Sep 28, 2011, at 4:26 PM, Quincey Morris wrote: > >> On Sep 28, 2011, at 15:50 , Philip McIntosh wrote: >> >>> I want the number in the display (which is a string representation of the >>> number) to be formatted as it is entered not after any "return" or >>> "calculate" keys are pressed. I can get it to format and display the string >>> correctly "after" such a key is pressed, no problem. >> >> I just went back and read as much of this thread as I could find (all of it, >> I think) because I wasn't paying much attention earlier. >> >> It seems to me you've created your own problem. You cannot re-create a >> string that represents certain user-entered state [i.e. a partially-entered >> number] if you run the input through a transformation that discards a vital >> piece of the state. Converting a string to a number to a string [for a >> partially-entered number] preserves *most* of the state, but not all of it, >> because the numeric conversion you're using isn't intended for a >> partially-entered number. >> >> Specifically, if the user has typed "1.000" on the way to "1.0002", the >> number to be converted is in fact 1.0002 even if partially entered. >> Pretending temporarily that it's a fully-entered "1.000" throws away the >> part of the state that represents partial completion, so the result is of >> course "1.". That's what you asked for. >> >> By replacing the partially user-entered string before the user has finished >> entering it, you are already abusing the Cocoa text field metaphor to some >> degree. I'm not sure if makes any difference to your "abusing the Cocoa text field metaphor to some degree" argument, but I am using a label not a textField. > > I suspect you're also going to confuse the undo manager. I've had issues in > the past when mixing it with formatters because the formatter changed the > value that the text field was using but undo didn't notice, and then tried to > undo more or less characters than were actually entered. I have not implemented any undo functionality, but thanks for the heads up. That will definitely have to be considered, since I was thinking about implementing undo at some point. I have it working now. Thanks for everyone's interest and input. On to the next problem.___ 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 Thu, Sep 29, 2011 at 12:33 PM, Kevin Perry wrote:
>
> On Sep 29, 2011, at 12:00 PM, Kyle Sluder wrote:
>
>> On Thu, Sep 29, 2011 at 9:20 AM, Kevin Perry wrote:
>>> If it were to call the fileAccessCompletionHandler any earlier then it might
>>> be possible, for example, for -fileModificationDate to be invoked on the
>>> main thread after -writeSafelyToURL: has written the file, but before the
>>> value has been properly updated.
>>
>> Thank you, this is enlightening. Your sketch omitted the "take a
>> snapshot of the document wrapper" part; I assume that comes prior to
>> the call to -performAsynchronousFileAccess…, but still within the same
>> enveloping call to -performActivityWithSynchronousWaiting:….
>
> For Versions, you mean? That also happens within
> -performAsynchronousFileAccess:, because we don't want anything else touching
> the file while we're preserving the version.
I was referring to -fileWrapperOfType:, which is described as being a
snapshot of the document's contents somewhere in the headerdocs. It's
the same thing you refer to at the end of your reply, so I think we're
on the same page here.
>> However, I am still concerned about blocking other apps. According to
>> the documentation, -performAsynchronousFileAccessUsingBlock: does not
>> block the main thread. But it surely has to block _something_ until
>> the fileAccessCompletionHandler is called.
>
> Yeah, it blocks further invocations of
> -perform(A)synchronousFileAccessUsingBlock:, where "block" means "enqueue"
> for async access, and "block the thread" for sync access.
Okay, so that explains how the following worked out for me.
I decided to try out what happened if I called NSRunAlertPanel from
within an entirely synchronous activity
(-performActivityWithSynchronousWaiting:YES, containing a call to
-performSynchronousFileActivity). Surprisingly, that didn't cause
deadlock:
- (IBAction)doActivity:(id)sender {
[self performActivityWithSynchronousWaiting:YES usingBlock:^(void
(^activityCompletionHandler)(void)){
[self performSynchronousFileAccessUsingBlock:^{
/* ... [[NSFileManager defaultManager] muckAbout:] ... */
}];
// Present an app-modal panel and don't return until the user clicks OK
NSRunAlertPanel(@"Deadlock?", @"We should be deadlocked.",
@"OK", nil, nil);
activityCompletionHandler();
}];
}
Surprisingly to me at first, this did not deadlock. We're inside a
call to -performActivityWithSynchronousWaiting:, so my mind kept
thinking "blocking the main thread" meant that I would not receive
user events to dismiss that panel. But of course, NSRunAlertPanel runs
the runloop. What _does_ get "blocked" (or "enqueued") are any calls
to -perform(A)SynchronousActivity that happen to be triggered by
-presentError:'s running of the runloop. Specifically, any calls to
-performSynchronousActivity block the thread, resulting in deadlock:
- (void)deadlockMe:(id)unused;
{
[self performActivityWithSynchronousWaiting:YES usingBlock:^(void
(^activityCompletionHandler)(void)){
NSLog(@"DEADLOCK?");
activityCompletionHandler();
}];
NSLog(@"WE ESCAPED DEADLOCK!");
}
- (IBAction)doActivity:(id)sender {
[self performActivityWithSynchronousWaiting:YES usingBlock:^(void
(^activityCompletionHandler)(void)){
[self performSynchronousFileAccessUsingBlock:^{
/* ... [[NSFileManager defaultManager] muckAbout:] ... */
}];
[self performSelector:@selector(deadlockMe:) withObject:nil
afterDelay:0 inModes:[NSArray arrayWithObject:NSRunLoopCommonModes]];
// Present an app-modal panel and don't return until the user clicks OK
NSRunAlertPanel(@"Deadlock?", @"We should be deadlocked.",
@"OK", nil, nil);
activityCompletionHandler();
}];
}
I think the source of confusion is overloading of the term "block." In
addition to referring to the block of code passed to
-performActivityWithSynchronousWaiting:, as well as actual blocking of
a thread via synchronization primitives such as semaphores, the
NSDocument headerdocs have introduced a new definition that means
"conceptually enqueue this activity and wait for its completion". Two
activities can become deadlocked on a single thread by attempting to
reentrantly call -performActivityWithSynchronousWaiting:YES. This
deadlock can block the thread's execution.
Case in point, here's where the terminology starts to get confusing:
>> Does
>> "-performAsynchronousFileAccess does not block the main thread" really
>> mean "if I can't execute the block now, I will execute it later, and
>> in doing so the thread on which this method was called (which might be
>> the main thread) will be blocked until the block has finished
>> executing _and_ the fileAccessCompletionHandler has been called"?
>
> No, because blocking the thread until fileAccessCompletionHandler is called
> would defeat the purpose of asynchronous saving. The thread is unblocked
> immediately
Re: creating multiple NSTimers
Sorry, I started this out wrong. I am probably over thinking this to the point of confusion. Here is where I am. I have an application for a facility that uses a number of ip enabled set top boxes to drive TV's throughout the place. Each box is to be shutdown at certain times of the day depending on what part of the facility is closed for the day. In my app the user sets up a configuration in an NSTable whereby each device is set to shut down at a certain time each day. From this configuration, I setup timers to correspond to the shutdown time and have them repeat each 24 hours. I originally thought I would simply load each into the runloop using NSTimers class method +scheduledTimerWithTimeInterval:target:selector:userinfo:repeats. without retaining a reference to it. But I ran into the problem of the user changing a device's shutdown time while the app is running. I needed to retain a reference to the timer to invalidate it . In other words, if the user comes along and wants to change the configuration (a shut down time) of one device while the app is running I need to be able to stop the timer that is currently in the run loop and use the new configuration. Without invalidating that timer would I not have an active timer in the run loop on top of what is created by new configuration? I then moved on the creating timers and instead of loading them into the run loop I would load them into an array and and sort them according to time. I then loop through the array loading only the first timer of the array into the run loop and retain a reference to it. Each firing of the timer loads the next timer into the run loop and retains a reference to it. But this has other issues particularly when firing times are real close together. At this point I need a fresh prospective on this. Any thoughts would be greatly appreciated. Tom On Sep 29, 2011, at 5:15 PM, David Duncan wrote: > I think you need to backup and explain exactly what your requirements are. If > you really do need to track these timers, you will probably need an array or > dictionary, but if these timers are all one-shot and they configure the next > timer to execute, there seems little reason to maintain your own owning > reference to them... > > On Sep 29, 2011, at 3:06 PM, Tom Hohensee wrote: > >> Yes. What I have worked on is using an array of timers fired sequentially. >> Each firing of the timer sets up the next one in the array. Each new >> addition to the array requires invalidating of the active timer and >> reordering of the array according to times. But i have run into problems >> when two or more timers are set to fire at the same time. >> >> Tom >> >> On Sep 29, 2011, at 4:51 PM, David Duncan wrote: >> >>> On Sep 29, 2011, at 2:47 PM, Tom Hohensee wrote: >>> However, I do not know wether the user will have 1 device or 100 devices. Do I have to setup a finite amount of timers (ultimately having a limit on the number of devices that can be added) or is there a better way? I have googled for a while now trying to find example code but have come up empty (plenty of finite examples). I see there are timer applications out there that seem to handle an infinite number of timers. >>> >>> >>> Have you looked into NSMutableArray? >>> -- >>> David Duncan >>> >>> ___ >>> >>> 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/tomhoh%40mac.com >>> >>> This email sent to tom...@mac.com >> > > -- > David Duncan > ___ 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
applicationWillFinishLaunching
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/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Core Data + Undo + Autosave = Instability? Was: … Undo Delete : Cannot fulfill fault
On 2011 Sep 29, at 11:20, Quincey Morris wrote: > I'm pretty sure … that Core Data undo *doesn't* work across 'save:' > boundaries. … If I'm right, you should be clearing the undo stack at a save, > at least if there are deleted objects in the picture. > Alternately, I'm completely wrong. I think you're correct, but not directly. The -[NSManagedObjectContext undo] method whose documentation you read so deftly is not involved. It does not get invoked when user clicks Edit ▸ Undo in a Cocoa application. * * * Like any normal app, my app's Edit ▸ Undo menu item targets First Responder. A careful reading of the documentation [1] reveals that the message is targeted to -[NSDocument undo]. There is no indication that NSPersistentDocument overrides -undo, either in the header nor the Class Reference document. Therefore, I don't care what -[NSManagedObjectContext undo] says because I'm not invoking it. The debugger tells me the same thing. A breakpoint in -[NSManagedObjectContext undo] does *not* break when user clicks Undo [2]. Apparently, -[NSManagedObjectContext undo] is only used in contexts that are not associated with a document, like a detail sheet or in a non-document-based app. * * * But since NSUndoManager is just a glorified container for invocations, and since the heavy lifting is done by -[NSManagedObjectContext _undoUpdates], it makes sense that the same limitation would apply, but was never documented. Clearing the undo stack upon save is obviously not acceptable – I've never seen any app do that. Clearing it only "if there are deleted objects in the picture" is not acceptable either because that situation is when the user wants it most. Apple's NSPersistentDocument tutorial sample (DepartmentAndEmployees) does not do that. My app opts in to Autosave In Place. If I cleared the undo stack upon save, Undo would never be available for more than 15 seconds. Jerry [1] There are only two -undo methods in Cocoa: in NSUndoManager and in NSManagedObjectContext, and no instance of either is in the responder chain. The paradox is explained in this document: Undo Architecture ▸ Using Undo in AppKit-Based Applications ▸ Undo and the Responder Chain "NSResponder declares the undoManager method for most objects that inherit from it (namely, windows and views). When the first responder of an application receives an undo or redo message, NSResponder goes up the responder chain looking for a next responder that returns anNSUndoManager object from undoManager. Any returned undo manager is used for the undo or redo operation." NSDocument is in the Responder Chain and implements -undoManager; thus, NSUndoManager gets the -undo message. [2] Astute readers of this thread will say "Aha, that's because you're using GCUndoManager instead of NSUndoManager". Yes, but for this test I switched a #if to use NSUndoManager. While I was there, I confirmed that I still get about the same 59% failure rate in my corner case, whether I'm using NSUndoManager or GCUndoManager. ___ 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
Forgot to send to list: > Perhaps, instead of timers, you use objects that represent one of these > set-top boxes and the time at which they should be shutdown. And instead of > scheduling and managing timer, you manage the domain objects instead. Then, > you have one timer, that checks all of your objects and sees if they should > be shut down. But when re-reading the thread I see this is exactly what John suggested: > Could you use a single, repeating timer with sufficient resolution for your > purposes and an array or dictionary storing the needed timing state? Then > update state appropriately at each fire of the single timer?" On Sep 29, 2011, at 7:48 PM, Tom Hohensee wrote: > Sorry, I started this out wrong. I am probably over thinking this to the > point of confusion. Here is where I am. > I have an application for a facility that uses a number of ip enabled set top > boxes to drive TV's throughout the place. Each box is to be shutdown at > certain times of the day depending on what part of the facility is closed for > the day. In my app the user sets up a configuration in an NSTable whereby > each device is set to shut down at a certain time each day. From this > configuration, I setup timers to correspond to the shutdown time and have > them repeat each 24 hours. I originally thought I would simply load each > into the runloop using NSTimers class method > +scheduledTimerWithTimeInterval:target:selector:userinfo:repeats. without > retaining a reference to it. But I ran into the problem of the user changing > a device's shutdown time while the app is running. I needed to retain a > reference to the timer to invalidate it . In other words, if the user comes > along and wants to change the configuration (a shut down time) of one device > while the app is running I need to be able to stop the timer that is > currently in the run loop and use the new configuration. Without > invalidating that timer would I not have an active timer in the run loop on > top of what is created by new configuration? I then moved on the creating > timers and instead of loading them into the run loop I would load them into > an array and and sort them according to time. I then loop through the array > loading only the first timer of the array into the run loop and retain a > reference to it. Each firing of the timer loads the next timer into the run > loop and retains a reference to it. But this has other issues particularly > when firing times are real close together. > > At this point I need a fresh prospective on this. Any thoughts would be > greatly appreciated. > > Tom > > > On Sep 29, 2011, at 5:15 PM, David Duncan wrote: > >> I think you need to backup and explain exactly what your requirements are. >> If you really do need to track these timers, you will probably need an array >> or dictionary, but if these timers are all one-shot and they configure the >> next timer to execute, there seems little reason to maintain your own owning >> reference to them... >> >> On Sep 29, 2011, at 3:06 PM, Tom Hohensee wrote: >> >>> Yes. What I have worked on is using an array of timers fired sequentially. >>> Each firing of the timer sets up the next one in the array. Each new >>> addition to the array requires invalidating of the active timer and >>> reordering of the array according to times. But i have run into problems >>> when two or more timers are set to fire at the same time. >>> >>> Tom >>> >>> On Sep 29, 2011, at 4:51 PM, David Duncan wrote: >>> On Sep 29, 2011, at 2:47 PM, Tom Hohensee wrote: > However, I do not know wether the user will have 1 device or 100 devices. > Do I have to setup a finite amount of timers (ultimately having a limit > on the number of devices that can be added) or is there a better way? I > have googled for a while now trying to find example code but have come up > empty (plenty of finite examples). I see there are timer applications > out there that seem to handle an infinite number of timers. Have you looked into NSMutableArray? -- David Duncan ___ 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/tomhoh%40mac.com This email sent to tom...@mac.com >>> >> >> -- >> David Duncan >> > > ___ > > 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-
Re: NSDocument Serialization (-performSynchronousFileAccessUsingBlock: and friends)
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? --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: creating multiple NSTimers
Timers are objects, and can be retained like any other independently of whether they are scheduled on a run loop or not. The run loop will additionally retain the timer, but that's its business. In the object that represents the set-top box, just add a 'timer' property (retained), so that you can get the timer associated with the box. Then you are free to invalidate it, reschedule it, add it or remove it from the run loop at will. While leaving the run loop to manage its timers is the usual M.O., if you need more control, then all you need to do is take it. Depending on how many set-top boxes there are likely to be (I'm guessing tens rather than thousands), then a separate timer per box is probably a good idea rather than have one timer which is repeatedly compared against a list of schedule times, which amounts to polling and hence will mean waking up the thread more often than necessary. --Graham On 30/09/2011, at 9:48 AM, Tom Hohensee wrote: > Sorry, I started this out wrong. I am probably over thinking this to the > point of confusion. Here is where I am. > I have an application for a facility that uses a number of ip enabled set top > boxes to drive TV's throughout the place. Each box is to be shutdown at > certain times of the day depending on what part of the facility is closed for > the day. In my app the user sets up a configuration in an NSTable whereby > each device is set to shut down at a certain time each day. From this > configuration, I setup timers to correspond to the shutdown time and have > them repeat each 24 hours. I originally thought I would simply load each into > the runloop using NSTimers class method > +scheduledTimerWithTimeInterval:target:selector:userinfo:repeats. without > retaining a reference to it. But I ran into the problem of the user changing > a device's shutdown time while the app is running. I needed to retain a > reference to the timer to invalidate it . In other words, if the user comes > along and wants to change the configuration (a shut down time) of one device > while the app is running I need to be able to stop the timer that is > currently in the run loop and use the new configuration. Without > invalidating that timer would I not have an active timer in the run loop on > top of what is created by new configuration? I then moved on the creating > timers and instead of loading them into the run loop I would load them into > an array and and sort them according to time. I then loop through the array > loading only the first timer of the array into the run loop and retain a > reference to it. Each firing of the timer loads the next timer into the run > loop and retains a reference to it. But this has other issues particularly > when firing times are real close together. > > At this point I need a fresh prospective on this. Any thoughts would be > greatly appreciated. ___ 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 4:48 PM, Tom Hohensee wrote: > Sorry, I started this out wrong. I am probably over thinking > this to the point of confusion. Here is where I am. I have an > application for a facility that uses a number of ip enabled set top > boxes to drive TV's throughout the place. Each box is to be > shutdown at certain times of the day depending on what part of the > facility is closed for the day. In my app the user sets up a > configuration in an NSTable whereby each device is set to shut down > at a certain time each day. From this configuration, I setup > timers to correspond to the shutdown time and have them repeat each > 24 hours. I originally thought I would simply load each into the > runloop using NSTimers class method > +scheduledTimerWithTimeInterval:target:selector:userinfo:repeats. > without retaining a reference to it. But I ran into the problem > of the user changing a device's shutdown time while the app is > running. I needed to retain a reference to the timer to invalidate > it . In other words, if the user comes along and wants to change > the configuration (a shut down time) of one device while the app > is running I need to be able to stop the timer that is currently in > the run loop and use the new configuration. Without invalidating > that timer would I not have an active timer in the run loop on top > of what is created by new configuration? I then moved on the > creating timers and instead of loading them into the run loop I > would load them into an array and and sort them according to time. > I then loop through the array loading only the first timer of the > array into the run loop and retain a reference to it. Each firing > of the timer loads the next timer into the run loop and retains a > reference to it. But this has other issues particularly when firing > times are real close together. > > At this point I need a fresh prospective on this. Any thoughts > would be greatly appreciated. OK, from the description I still don't see why you couldn't schedule the timers on the run loop and keep references to them in an appropriately keyed dictionary. When someone needs to edit the shutdown time you simply fetch the timer from the dictionary and - -setFireDate:. You would also have the ability to invalidate timers and remove them from the dictionary. Just make sure you remove the timers from the dictionary once fired/invalidated. (You could probably avoid this step by using zeroing weak references if you really wanted.) The polling approach described by John and Jamie would presumably also work, but I would consider the dictionary approach more straightforward. - -- Conrad Shultz Synthetiq Solutions www.synthetiqsolutions.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFOhQ1saOlrz5+0JdURAvEhAKCK7mCy5d/Y2Byx3CrKGPtyJ2PgowCffXNt oCPRXWNVcHVyCLeRIuGQSyI= =dH8W -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: applicationWillFinishLaunching
I'm not sure why it isn't being called (spelled wrong?), but if you want to put up a dialog box at this time, you won't be able to. A dialog box needs a running run loop to handle its events, and the run loop isn't running at this time. What will happen is that the dialog will come up, then the method returns, the app continues launching, opens all its windows, then starts to handle events for the dialog. The upshot is that the normal windows will open behind the dialog box, probably not what you intended. Getting this right is a real pain - despite asking via Radar for a standard supported way to show a modal window during app launch, this has not been added. In Lion it's even more painful with all the new document resuming stuff that goes on. Essentially, you need to determine if you need to show the dialog, and if you plan to, then suppress all the normal window opening (the app delegate has methods to allow/disallow it). When the app finishing launching, show the dialog. Afterwards, you'll need to open a new document or somehow trigger the opening of all the ones the user expected, which means you will have had to capture enough information during launch to determine what those would have been. It's a royal pain. --Graham On 30/09/2011, at 9:48 AM, koko wrote: > 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. ___ 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: delegate of an NWindowController's window
Thanks for the response, but, still not working.
Here's in more detail what I'm trying to do. My main window is controlled by
MyAppDelegate:
@interface MyAppDelegate : NSObject
In MyAppDelegate I respond to an IBAction to open a second window to generate
some data that needs to be go back to MyAppDelegate to put in my model. The
second window is controlled by MyDataWindowController, a subclass of
NSWindowController.
- (IBAction)showDataWindow:(id)sender
{
MyDataWindowController *searchDataWindow = [[MyDataWindowController alloc]
initWithWindowNibName:
@"searchDataWindow"];
[NSApp beginSheet:[searchDataWindow window]
modalForWindow:[self window]
modalDelegate: self
didEndSelector: nil
contextInfo: NULL];
}
This all goes fine, the sheet opens and I get generate the data, stored in an
NSDictionary in MyDataWindowController. Now I want somehow to get the data
back to MyAppDelegate. So I am trying this in MyDataWindowController:
At the top of MyDataWindowController I add this @protocol:
@protocol MyDataWindowControllerDelegate
- (void)insertData: (NSMutableDictionary *)data;
@end
and then after the data is obtained:
id del = [self delegate]; //
<---
if ([del respondsToSelector:@selector(insertData:)])
{
[del insertData: data];
}
}
[NSApp endSheet: [self window] returnCode: 1];
[[self window] orderOut: self];
Which now gives the warning:
Semantic Issue: Instance method '-delegate' not found (return type defaults to
'id') on the line with the arrow.
Any suggestions how to make this work? Maybe not use a delegate?
Thanks,
- Koen.
___
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? Was: … Undo Delete : Cannot fulfill fault
On Sep 29, 2011, at 16:50 , Jerry Krinock wrote: > The -[NSManagedObjectContext undo] method […] does not get invoked when user > clicks Edit ▸ Undo in a Cocoa application. I dunno. The issue isn't whether the method gets invoked. The issue is whether the property data that's needed to undo the deletion of an object is available after a 'save:'. I was using the documentation as evidence that it's not. (The other evidence being that your test fails 59% of the time.) > Like any normal app, my app's Edit ▸ Undo menu item targets First Responder. > A careful reading of the documentation [1] reveals that the message is > targeted to -[NSDocument undo]. There is no indication that > NSPersistentDocument overrides -undo, either in the header nor the Class > Reference document. Therefore, I don't care what -[NSManagedObjectContext > undo] says because I'm not invoking it. You misread the the first document you linked. As you correctly said: > "NSResponder declares the undoManager method for most objects that inherit > from it (namely, windows and views). When the first responder of an > application receives an undo or redo message, NSResponder goes up the > responder chain looking for a next responder that returns anNSUndoManager > object from undoManager. Any returned undo manager is used for the undo or > redo operation." > > NSDocument is in the Responder Chain and implements -undoManager; thus, > NSUndoManager gets the -undo message. So the 'undo' action message is going to end up at NSUndoManager, not NSDocument. However, I'm just being nitpicky. NSUndoManager can't undo anything, but it invokes an undo action. That action may not be (or invoke) [NSManagedObjectContext undo], but it certainly could be (or invoke) the same thing that method invokes. The point is what I said before: it sounds like the necessary property information is (deliberately) discarded by Core Data at 'save:' time. > Clearing the undo stack upon save is obviously not acceptable – I've never > seen any app do that. Believe it or not, back in Mac Classic days, it was far more usual for undo *not* to work across saves. The feature became widely available in Mac OS X because NSDocument made it easy to do. However, that doesn't necessarily mean the abomination that is NSPersistentDocument can also do it. > Clearing it only "if there are deleted objects in the picture" is not > acceptable either because that situation is when the user wants it most. Actually, where I was going with this was that there might be a workaround by *not* deleting Core Data objects in response to what the user thinks of as a delete, but simply put them in stealth mode as far as visibility to the user is concerned, and let them get garbage-collected out of existence only when no longer referenced, not even by undo actions. Even that probably sounds horrific to you, but if Core Data undo really does require the objects to *exist* in the persistent store in order to be reliably undoable, then you simply can't delete them when you, er, delete them. Anyway, only someone from Apple can now speak definitively on this issue, I think. ___ 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: delegate of an NWindowController's window
You're overthinking the problem.
NSWindowController doesn't have a 'delegate' method or property, which is the
cause of the warning you are receiving.
Using a delegate to handle the result from a sheet is reasonable - it's what I
invariably do. But you have to add that delegate property yourself in your
NSWindowController subclass. This can be a simple assigned ivar:
@interface MyWindowController : NSWindowController
{
id delegate;
}
@property (assign) id delegate;
@end
I would also not bother with a formal protocol for the delegate callback. Since
you are checking whether the delegate responds to the selector, it may as well
be an informal protocol, which is easier to set up.
Informal protocols are declared using a category on (usually) NSObject:
@interface NSObject (MyWindowControllerDelegate)
- (void)windowController:(MyWindowController*) controller
insertData:(NSDictionary*) dict;
@end
This also shows you two tips:
a) pass the controller that is doing the setting - there may come a time that
you want to tell apart different ones, or request other information from the
controller.
b) pass the data as a dictionary, not a mutable dictionary. The client should
not be given any opportunity to mutate things that it has no business mutating.
--Graham
On 30/09/2011, at 10:38 AM, Koen van der Drift wrote:
> Thanks for the response, but, still not working.
>
>
> Here's in more detail what I'm trying to do. My main window is controlled by
> MyAppDelegate:
>
> @interface MyAppDelegate : NSObject
>
>
> In MyAppDelegate I respond to an IBAction to open a second window to generate
> some data that needs to be go back to MyAppDelegate to put in my model. The
> second window is controlled by MyDataWindowController, a subclass of
> NSWindowController.
>
> - (IBAction)showDataWindow:(id)sender
> {
>MyDataWindowController *searchDataWindow = [[MyDataWindowController alloc]
> initWithWindowNibName:
> @"searchDataWindow"];
>[NSApp beginSheet:[searchDataWindow window]
> modalForWindow:[self window]
>modalDelegate: self
> didEndSelector: nil
> contextInfo: NULL];
> }
>
> This all goes fine, the sheet opens and I get generate the data, stored in an
> NSDictionary in MyDataWindowController. Now I want somehow to get the data
> back to MyAppDelegate. So I am trying this in MyDataWindowController:
>
> At the top of MyDataWindowController I add this @protocol:
>
> @protocol MyDataWindowControllerDelegate
> - (void)insertData: (NSMutableDictionary *)data;
> @end
>
> and then after the data is obtained:
>
>id del = [self delegate]; //
> <---
>
>if ([del respondsToSelector:@selector(insertData:)])
>{
>[del insertData: data];
>}
>}
>
>[NSApp endSheet: [self window] returnCode: 1];
>[[self window] orderOut: self];
>
> Which now gives the warning:
>
> Semantic Issue: Instance method '-delegate' not found (return type defaults
> to 'id') on the line with the arrow.
>
>
>
> Any suggestions how to make this work? Maybe not use a delegate?
>
>
> Thanks,
>
> - Koen.
>
>
>
>
>
>
> ___
>
> 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/graham.cox%40bigpond.com
>
> This email sent to graham@bigpond.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
Bingo! Thanks. This is where I was going wrong. I saw John and Jamie's responses earlier and got me thinking in objects again. But still wasn't putting it together. I had a mental block and was not thinking of the timers as properties of the boxes. Just kept getting stuck on the NSTimer object being the object. Man it is hard to get off of a train of though sometimes. Ultimately each facility has between 20 and 30 boxes. I really did not want to poll. Thanks again Tom On Sep 29, 2011, at 7:27 PM, Graham Cox wrote: > Timers are objects, and can be retained like any other independently of > whether they are scheduled on a run loop or not. The run loop will > additionally retain the timer, but that's its business. > > In the object that represents the set-top box, just add a 'timer' property > (retained), so that you can get the timer associated with the box. Then you > are free to invalidate it, reschedule it, add it or remove it from the run > loop at will. While leaving the run loop to manage its timers is the usual > M.O., if you need more control, then all you need to do is take it. > > Depending on how many set-top boxes there are likely to be (I'm guessing tens > rather than thousands), then a separate timer per box is probably a good idea > rather than have one timer which is repeatedly compared against a list of > schedule times, which amounts to polling and hence will mean waking up the > thread more often than necessary. > > --Graham > > > On 30/09/2011, at 9:48 AM, Tom Hohensee wrote: > >> Sorry, I started this out wrong. I am probably over thinking this to the >> point of confusion. Here is where I am. >> I have an application for a facility that uses a number of ip enabled set >> top boxes to drive TV's throughout the place. Each box is to be shutdown >> at certain times of the day depending on what part of the facility is closed >> for the day. In my app the user sets up a configuration in an NSTable >> whereby each device is set to shut down at a certain time each day. From >> this configuration, I setup timers to correspond to the shutdown time and >> have them repeat each 24 hours. I originally thought I would simply load >> each into the runloop using NSTimers class method >> +scheduledTimerWithTimeInterval:target:selector:userinfo:repeats. without >> retaining a reference to it. But I ran into the problem of the user >> changing a device's shutdown time while the app is running. I needed to >> retain a reference to the timer to invalidate it . In other words, if the >> user comes along and wants to change the configuration (a shut down time) of >> one device while the app is running I need to be able to stop the timer that >> is currently in the run loop and use the new configuration. Without >> invalidating that timer would I not have an active timer in the run loop on >> top of what is created by new configuration? I then moved on the creating >> timers and instead of loading them into the run loop I would load them into >> an array and and sort them according to time. I then loop through the array >> loading only the first timer of the array into the run loop and retain a >> reference to it. Each firing of the timer loads the next timer into the run >> loop and retains a reference to it. But this has other issues particularly >> when firing times are real close together. >> >> At this point I need a fresh prospective on this. Any thoughts would be >> greatly appreciated. > > ___ > > 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/tomhoh%40mac.com > > This email sent to tom...@mac.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: delegate of an NWindowController's window
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 9/29/11 5:38 PM, Koen van der Drift wrote:
> This all goes fine, the sheet opens and I get generate the data,
> stored in an NSDictionary in MyDataWindowController. Now I want
> somehow to get the data back to MyAppDelegate. So I am trying this
> in MyDataWindowController:
...
> id del = [self delegate]; //
> <---
>
> if ([del respondsToSelector:@selector(insertData:)]) { [del
> insertData: data]; } }
>
> [NSApp endSheet: [self window] returnCode: 1]; [[self window]
> orderOut: self];
>
> Which now gives the warning:
>
> Semantic Issue: Instance method '-delegate' not found (return type
> defaults to 'id') on the line with the arrow.
As Graham mentioned, NSWindowController does not have a -delegate
method. The compiler seems to be telling you that you didn't
implement one yourself either.
If I had to hazard a guess, I would surmise that you are getting
tripped up by the fact that NSWindow DOES respond to -delegate and, in
practice, one often sets an NSWindow's delegate to be an
NSWindowController instance.
So, you could declare a delegate property on MyDataWindowController
and handle it that way.
An alternate approach, depending on the details of your
implementation, might be to make use of some of the other parameters
in that lengthy -beginSheet... method; setting appropriate values for
didEndSelector (and, potentially, contextInfo if your design requires
it) can probably get you what you need.
- --
Conrad Shultz
Synthetiq Solutions
www.synthetiqsolutions.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iD8DBQFOhRViaOlrz5+0JdURAroXAJ4tO2WAshz1c/UpyoLnq6Q7s+VvkwCeLHiC
jPPm4IuWqlE5rnxhxmBZ7W0=
=6cVo
-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: Cocoa-dev Digest, Vol 8, Issue 783
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. On 9/29/11 8:06 PM, "cocoa-dev-requ...@lists.apple.com" wrote: >> > Perhaps, instead of timers, you use objects that represent one of these >> set-top boxes and the time at which they should be shutdown. And instead of >> scheduling and managing timer, you manage the domain objects instead. Then, >> you have one timer, that checks all of your objects and sees if they should >> be shut down. > > > But when re-reading the thread I see this is exactly what John suggested: > >> > Could you use a single, repeating timer with sufficient resolution for your >> purposes and an array or dictionary storing the needed timing state? Then >> update state appropriately at each fire of the single timer?" ___ 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
Whoops, didn¹t reset the title. Sorry. On 9/29/11 8:25 PM, "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. > > > On 9/29/11 8:06 PM, "cocoa-dev-requ...@lists.apple.com" > wrote: > >>> > Perhaps, instead of timers, you use objects that represent one of these >>> set-top boxes and the time at which they should be shutdown. And instead of >>> scheduling and managing timer, you manage the domain objects instead. Then, >>> you have one timer, that checks all of your objects and sees if they should >>> be shut down. >> >> >> But when re-reading the thread I see this is exactly what John suggested: >> >>> > Could you use a single, repeating timer with sufficient resolution for >>> your purposes and an array or dictionary storing the needed timing state? >>> Then update state appropriately at each fire of the single timer?" > ___ 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: Cocoa-dev Digest, Vol 8, Issue 783
On 30/09/2011, at 11:25 AM, Gordon Apple wrote: > Much easier than trying to manage timers. I disagree. Timers are not rocket science, and they are optimised (one assumes) not to consume more CPU time than they truly need. Your idea is more complicated and is polling, meaning that you are consuming more power and resources than necessary. Do you wake up every minute during the night to check whether it's time to get up? No, so you shouldn't program a computer the same way. --Graham ___ 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: Cocoa-dev Digest, Vol 8, Issue 783
Fair point, Graham. I'm always wary of timers because careless use of them can cause problems like retain cycles. Sent from my iPhone On Sep 29, 2011, at 9:35 PM, Graham Cox wrote: > > On 30/09/2011, at 11:25 AM, Gordon Apple wrote: > >> Much easier than trying to manage timers. > > > I disagree. Timers are not rocket science, and they are optimised (one > assumes) not to consume more CPU time than they truly need. Your idea is more > complicated and is polling, meaning that you are consuming more power and > resources than necessary. Do you wake up every minute during the night to > check whether it's time to get up? No, so you shouldn't program a computer > the same way. > > --Graham > > > ___ > > 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/jamiepinkham%40me.com > > This email sent to jamiepink...@me.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: delegate of an NWindowController's window
On Sep 29, 2011, at 9:03 PM, Conrad Shultz wrote: > > An alternate approach, depending on the details of your > implementation, might be to make use of some of the other parameters > in that lengthy -beginSheet... method; setting appropriate values for > didEndSelector (and, potentially, contextInfo if your design requires > it) can probably get you what you need. This is what I ended up doing, and it works. It took me a while to figure out how to use contextInfo, but I found an example here: http://www.digitalenginesoftware.com/blog/archives/54-The-proper-care-and-feeding-of-NSWindow-objects-display-as-a-sheet.html Thanks, - Koen. ___ 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: debugging crashes in dyld?
On Tue, Sep 27, 2011 at 2:06 PM, Martin Wierschin wrote: > I have a user reporting a crash whenever they try to first save a file. It is > reproducible for the user (though not be me) and I'm wondering how to best > debug this problem remotely. I've included the crash stack below (all other > threads are waiting/trapped). Your stack includes the dlopen function. What that does is "manually" load a dynamic library, that is, code that either you are Apple's engineers wrote is loading a dynamic library by name at runtime, rather than being linked at build time and loaded by the system at application launch. The dtruss command will print out the system calls that your app makes - or that frameworks that your app links to call: http://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPages/man1/dtruss.1m.html http://humberto.digi.com.br/blog/2008/02/25/strace-on-mac-os-x-leopard/ Write a shell script to have your user run, that will launch your app under dtruss while saving its output to a text file, then ask your user to send you that text file. Search in it for "dlopen", and it should show you which shared library is being loaded. That library may be the executable withing a framework, or it may be a vanilla dylib in /usr/bin or some such. If it's not enough to just find out which dylib is causing the crash, it might be worthwhile to write your own "shim" dylib that is inserted in place of the real one somehow, that has all the same entry points but records all their parameters, then loads the real shared library and passes the call on. If you are careful about it you could have your user replace his original shared library with yours, while moving the original to some other name that your shim knows how to load. This would be a little dangerous; if the dylib is important and you screw up, your user might have to reinstall OS X, so make sure you get it right. -- Don Quixote de la Mancha quix...@dulcineatech.com Custom Software Development for the iPhone and Mac OS X http://www.dulcineatech.com/custom-software-development/ ___ 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
iTunes problem related to free space on device (iPad, iPod ) when transferring data to device.
Hi All, I am transferring audio files to iPod, iPad using iTunes programatically. We have noticed that iTunes does not transfer the file\track\book to the device (iPad / iPod), even if size of the data to transfer is less than the available free space of the device. for ex. The free space available on device is 235077632 bytes while size of data to be transferred is 127047109 bytes, but iTunes gives the pop up that "There is not enough space on device to transfer all the requested files…" when transfer is initiated. Is there a threshold\margin free space of fixed size (bytes) per device (iPod, iPad) that is kept free on the device. Does that threshold\margin vary as a percentage of the total device capacity or with device type. Basically, when programmatically transferring an audiobook to iPad/iPod, we want to be sure that there is enough free space available on the device before initiating the transfer. It will be great if anybody could help on this. Thanks & regards, Payal. DISCLAIMER == This e-mail may contain privileged and confidential information which is the property of Persistent Systems Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Ltd. does not accept any liability for virus infected mails. ___ 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
Managed Object Model versions
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/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Finder Integration
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: creating multiple NSTimers
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. -- GG ___ 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 11:20 AM, Quincey Morris wrote: > I think the answer to your original question is that You're Doing It Wrong™. > :) > > I'm pretty sure (though I never really thought about it before today) that > Core Data undo *doesn't* work across 'save:' boundaries. The documentation > for [NSManagedObjectContext undo:] says this: > >> "Sends an undo message to the receiver’s undo manager, asking it to reverse >> the latest uncommitted changes applied to objects in the object graph." > > > Note that word "uncommitted". After 'save:', all changes are committed, so > you're not permitted to undo past that point. At least, that's how I read it. That documentation is unfortunately confusing. Someone should file a bug to have it clarified. 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. A trivial NSPersistentDocument sample application handles undo correctly across save boundaries for both property changes and deletes. Jerry Krinock wrote: > It's always the same "exceptional" object which whose deletion is unable to > be undone because Core Data could not fulfill a fault. Its parent is an > object that was not deleted and therefore does not need to be restored. It > has one child which has already been successfully restored at the time the > exception occurs. 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.) If you can isolate this into a standalone sample, (and in the process haven’t found a bug in your code causing it) you can file a radar and post a link to the sample here and maybe we can offer further advice. —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: iTunes problem related to free space on device (iPad, iPod ) when transferring data to device.
This may be a bug in either iTunes or the iOS. If you think it might be, you should file a bug report at: http://bugreport.apple.com/ -- Don Quixote de la Mancha quix...@dulcineatech.com Custom Software Development for the iPhone and Mac OS X http://www.dulcineatech.com/custom-software-development/ ___ 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
