Hi Graham,
First of all, -printShowingPrintPanel: is deprecated. I believe if you were to
stop overriding that method and use -printOperationWithSettings:error: and
-runModalPrintOperation:delegate:didRunSelector:contextInfo: instead the
problem would go away.
Otherwise, you've found the crux of your problem with your backtrace. There are
two nested invocations of -performActivityWithSynchronousWaiting:usingBlock:,
which without the use of -continueActivityUsingBlock:, behave like
non-recursive locks, leading to deadlock when you call them re-entrantly.
Simply wrap your invocation of -runModalPrintOperation: in the block argument
of -continueActivityUsingBlock: and it should work correctly.
-KP
On Aug 22, 2011, at 8:00 PM, Graham Cox wrote:
> I set a breakpoint on -[NSDocument
> performActivityWithSynchronousWaiting:usingBlock:]
>
>
> It is hit exactly twice in my test case, both in the same call stack, which
> is:
>
> #0 0x00007fff881b2464 in -[NSDocument
> performActivityWithSynchronousWaiting:usingBlock:] ()
> #1 0x00007fff881a2518 in -[NSDocument
> runModalPrintOperation:delegate:didRunSelector:contextInfo:] ()
> #2 0x000000010009e454 in -[GCOrteliusDocument
> runModalPrintOperation:delegate:didRunSelector:contextInfo:] at
> /Users/grahamcox/Projects/Artboard/Artboard/Source/Code/GCOrteliusDocument.m:1464
> #3 0x00000001002f59fc in -[DKDrawingDocument printShowingPrintPanel:] at
> /Users/grahamcox/Projects/DrawKit/DrawKit/../Source/Code/DKDrawingDocument.m:923
> #4 0x00007fff881a1a52 in __-[NSDocument
> printDocumentWithSettings:showPrintPanel:delegate:didPrintSelector:contextInfo:]_block_invoke_2
> ()
> #5 0x00007fff881a95e0 in -[NSDocument _commitEditingThenContinue:] ()
> #6 0x00007fff881a52ab in -[NSDocument
> _commitEditingWithDelegate:didSomethingSelector:contextInfo:thenContinue:] ()
> #7 0x00007fff881a18bf in __-[NSDocument
> printDocumentWithSettings:showPrintPanel:delegate:didPrintSelector:contextInfo:]_block_invoke_1
> ()
> #8 0x00007fff881b2670 in -[NSDocument
> performActivityWithSynchronousWaiting:usingBlock:] ()
> #9 0x00007fff881a17d1 in -[NSDocument
> printDocumentWithSettings:showPrintPanel:delegate:didPrintSelector:contextInfo:]
> ()
> #10 0x00007fff881a1763 in -[NSDocument printDocument:] ()
> #11 0x00007fff90c4d11d in -[NSObject performSelector:withObject:] ()
>
>
> The first time it is hit is at line #8, the second time at line number #0. It
> is not hit at any time prior to this - all I'm doing is launching my app and
> choosing "Print…".
>
> I tried removing my override of runModalPrintOperation…, which had no effect.
> That leaves the only override -printShowingPrintPanel, but of course that has
> to be overridden or else Print does nothing. That method creates a view and
> associates it with my data model so it can render its contents. Previously
> that has never given me any trouble, though I'll investigate further.
>
> That method is:
>
> - (void) printShowingPrintPanel:(BOOL) flag
> {
> DKDrawingView* pdv = [[self makePrintDrawingView] retain];
> DKViewController* vc = [pdv makeViewController];
>
> [[self drawing] addController:vc];
>
> NSPrintInfo* printInfo = [self printInfo];
>
> [pdv setPrintInfo:printInfo];
> [pdv setPrintCropMarkKind:[[self mainView] printCropMarkKind]];
>
> NSPrintOperation* printOp = [NSPrintOperation
> printOperationWithView:pdv printInfo:printInfo];
>
> [printOp setShowsPrintPanel:flag];
> [self runModalPrintOperation:printOp delegate:self
> didRunSelector:@selector(documentDidRunModalPrintOperation:success:contextInfo:)
> contextInfo:NULL];
>
> [pdv release]; //removes the controller from the drawing when view
> dealloced
> }
>
> While this calls out to other methods, it's all pretty simple - makes a view,
> associates it with the existing data model owned by the document, and creates
> a print operation with that view, which is then passed along to the modal
> print op. All very standard I believe. I will attempt to cut this down to a
> simpler case just to try and eliminate it. But at no point does it invoke
> performActivityWithSynchronousWaiting:usingBlock:
>
> Seems to me if Kevin Perry's comment is taken at face value, the first
> invocation at line #8 is not completing, and so the second invocation is
> blocking. If some prior code had not completed, line 8 would block, not line
> 0. But NO code of mine is run prior to line #8, so I've hit another wall.
>
>
> --Graham
>
>
>
>
>
>
>
>
> On 23/08/2011, at 12:05 PM, Graham Cox wrote:
>
>> On 23/08/2011, at 11:43 AM, Jerry Krinock wrote:
>>
>>> "Here is a list of NSDocument methods whose default implementations invoke
>>> this method because they might present sheets, either to ask the user what
>>> to do as they begin their work or because they may fail and present errors
>>> to user:
>>> -revertDocumentToSaved:
>>> -saveDocumentWithDelegate:didSaveSelector:contextInfo:
>>> -runModalSavePanelForSaveOperation:delegate:didSaveSelector:contextInfo:
>>> -saveToURL:ofType:forSaveOperation:delegate:didSaveSelector:contextInfo:
>>> -canCloseDocumentWithDelegate:shouldCloseSelector:contextInfo:
>>> -duplicateDocumentWithDelegate:didDuplicateSelector:contextInfo:
>>> -runModalPageLayoutWithPrintInfo:delegate:didRunSelector:contextInfo:
>>> -printDocumentWithSettings:showPrintPanel:delegate:didPrintSelector:contextInfo:
>>> -runModalPrintOperation:delegate:didRunSelector:contextInfo:
>>> More uses of this method may be added to NSDocument in the future."
>>
>>
>> Thanks Jerry - I just found the same documentation. Still trying to get my
>> head around what it's actually saying…
>
_______________________________________________
Cocoa-dev mailing list ([email protected])
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 [email protected]
