On 22/08/2013, at 5:59 PM, Graham Cox wrote:
> I suggest logging 'self' at the point you set up your undo. If you can
> trigger the bug, then this will tell you what the real object responsible for
> the exception is - at the moment NSProxy is hiding it from you.
Thanks, I'm trying that, altho
On 22/08/2013, at 9:43 AM, Shane Stanley wrote:
> Not that I can see. Unless…
I suggest logging 'self' at the point you set up your undo. If you can trigger
the bug, then this will tell you what the real object responsible for the
exception is - at the moment NSProxy is hiding it from you.
On 22/08/2013, at 3:42 PM, Graham Cox wrote:
> Is there is any possibility that 'self' is not what you think it is? If
> that's confused, then the proxy is simply reflecting the fact that the object
> 'self' points to doesn't respond to the selector (since its own
> -respondsToSelector: method
On 22/08/2013, at 1:03 AM, Shane Stanley wrote:
> *** Terminating app due to uncaught exception 'NSInvalidArgumentException',
> reason: '*** -[NSProxy doesNotRecognizeSelector:unCompileWith:at:and:]
> called!'
> terminate called throwing an exception
> Right, that's the method I posted earlie
On 21/08/2013, at 11:51 PM, Graham Cox wrote:
> So what's the actual error (the title of the email seems incomplete)?
*** Terminating app due to uncaught exception 'NSInvalidArgumentException',
reason: '*** -[NSProxy doesNotRecognizeSelector:unCompileWith:at:and:] called!'
terminate called thro
So what's the actual error (the title of the email seems incomplete)?
If NSProxy is the receiver, that's most likely the NSProxy that NSUndoManager
returns from -prepareWithInvocationTarget: The proxy should forward absolutely
everything to the NSUndoManager, except possibly certain messages tha
On 21/08/2013, at 10:03 PM, Graham Cox wrote:
> The arguments are retained, but the target is not. Does knowing that make any
> difference to your memory managment analysis?
I don't think so. The target is the window controller in a document-based app,
created with -initWithWindowNibName: and
On 21/08/2013, at 1:24 PM, Shane Stanley wrote:
> If I understand correctly, the arguments when I use
> prepareWithInvocationTarget: are retained. In this case the target is the
> document's sole window controller and owner of the nib, so it's not like it's
> disappearing.
The arguments are
