On Mar 2, 2013, at 17:11 , Graham Cox wrote:
> Unless you send -retainArguments to it, in which case it, well, does what it
> says on the tin.
OK, but it's still a bit more complicated than that. Using the override code
suggested in the AppKit release notes I linked to, you also have to deal w
On 03/03/2013, at 11:05 AM, Quincey Morris
wrote:
> The other gotcha is that NSInvocation doesn't take ownership of any objects
> referred to by its arguments. That means being very careful when using ARC,
> since it can't memory-manage them for you.
Unless you send -retainArguments to it,
On Mar 2, 2013, at 13:17 , "Mills, Steve" wrote:
> But I'm not calling runModalPrintOperation, nor do I want to, because we need
> to do something completely different at this point. This is the reason I'm
> overriding printDocumentWithSettings in the first place. I just need to know
> how to
On Mar 2, 2013, at 1:17 PM, "Mills, Steve" wrote:
> On Mar 2, 2013, at 15:06, "Kyle Sluder" wrote:
>
>> The documentation is pretty clear about how NSDocument's default
>> implementation works. -[NSDocument
>> runModalPrintOperation:delegate:didPrintSelector:context:] is what actually
>> mes
On Mar 2, 2013, at 15:06, "Kyle Sluder" wrote:
> The documentation is pretty clear about how NSDocument's default
> implementation works. -[NSDocument
> runModalPrintOperation:delegate:didPrintSelector:context:] is what actually
> messages the delegate with the didPrintSelector. As long as you
On Mar 2, 2013, at 12:16 PM, Steve Mills wrote:
> Perhaps the problem is that my
> printDocumentWithSettings:showPrintPanel:delegate:didPrintSelector:contextInfo
> method doesn't call the selector when we're finished printing. I don't
> understand how to call the delegate with that selector an
Perhaps the problem is that my
printDocumentWithSettings:showPrintPanel:delegate:didPrintSelector:contextInfo
method doesn't call the selector when we're finished printing. I don't
understand how to call the delegate with that selector and can't find any
examples of this. Any pointers? Code sam
On Mar 1, 2013, at 14:59 , Steve Mills wrote:
> Sorry, I still consider myself a newbie in Cocoaland. I can add those open
> and print overrides to my NSApplicationDelegate, but I only want to be able
> to set breakpoints on them but still let the default behavior happen. Since
> NSApplication
On Mar 1, 2013, at 16:21:35, Quincey Morris
wrote:
> I think the diversion into Apple Events is something of a red herring, at
> least at this stage of your debugging. Requests to open and print may indeed
> arrive at your app as Apple Events, but the best place to intervene is in
> NSApplica
On Mar 1, 2013, at 13:59 , Steve Mills wrote:
> I have tons of experience with AppleEvents under Carbon, but none under
> Cocoa. Where does that event come in?
I think the diversion into Apple Events is something of a red herring, at least
at this stage of your debugging. Requests to open and
On Feb 28, 2013, at 02:35:18, Uli Kusterer wrote:
> Opening internally sends Apple Events. Have you checked whether the"open
> document" Apple event is sent and whether it looks any different? My guess is
> they won't use that for the open panel, but maybe they do and something's
> broken ther
Opening internally sends Apple Events. Have you checked whether the"open
document" Apple event is sent and whether it looks any different? My guess is
they won't use that for the open panel, but maybe they do and something's
broken there?
Cheers,
-- Uli Kusterer
"The Witnesses of TeachText are
I'm seeing a situation where, after successfully opening, NOT printing, and
then closing a document x number of times via Finder's Print command, our app
will stop receiving requests to open the same or any other document. I've added
an override for initWithContentsOfURL:ofType:error: just to se
13 matches
Mail list logo
