Re: Problem with NSTextView

[Fred Kiefer]

On 28.01.2012 17:44, Sebastian Reitenbach wrote:
> On Saturday, January 28, 2012 14:44 CET, David Chisnall<theraven@sucs.org>  
> wrote:
>
> > Hi Sebastian,
> >
> > If you put a breakpoint on objc_selector_type_mismatch, you will enter the 
> > debugger whenever this is warning will be printed.
>
> OK, so I did (actually it did not picked it up, so I set a breakpoint on 
> fprintf)
>
> I found in -gui, NSText, NSImageView, and NSMovieView, the copy: and paste: 
> methods return values are void.
>
> but in NSPasteboard.m, the example there for paste: suggests to return id, it 
> does a return self; at the end.
>
> I haven't found a method copy: paste: method declared with id as return value. 
> But my guess now is that
> this comes from Gorm.
>
>
> I also wonder, why the hell it checks this that often. For example, in 
> Addresses, I edit a field, and then hover with the mouse
> over the application window. While doing so, I can see, the console gets 
> spammed with the mentioned warning.
> So I wonder why its checking for copy: and paste: at all just because I move my 
> mouse over the application.
>
> #0  fprintf (fp=0x2d086310, fmt=0x2ccc6c6f "Calling [%s %c%s] with incorrect 
> signature.  Method has %s, selector has %s\n")
>      at /usr/src/lib/libc/stdio/fprintf.c:44
> #1  0x0ccdb448 in objc_selector_type_mismatch (cls=0xcfbd5274, 
> selector=0xcfbd5274, result=0xcfbd5274) at sendmsg2.c:37
> #2  0x0ccdc22c in objc_get_slot (cls=Unhandled dwarf expression opcode 0x0
> ) at sendmsg2.c:307
> #3  0x0ccdc26f in class_respondsToSelector (cls=dwarf2_read_address: Corrupted 
> DWARF expression.
> ) at sendmsg2.c:322
> #4  0x0a102e78 in -[NSObject respondsToSelector:] (self=dwarf2_read_address: 
> Corrupted DWARF expression.
> ) at NSObject.m:2096
> #5  0x09977ff1 in -[NSApplication(Private) 
> _targetForAction:keyWindow:mainWindow:] (self=0x8a57a984, _cmd=0x29805088,
>      aSelector=0x8be49550, keyWindow=0x7fbfe304, mainWindow=0x7fbfe304) at 
> NSApplication.m:3897
> #6  0x0996dae1 in -[NSApplication targetForAction:] (self=0x8a57a984, 
> _cmd=0x29804d08, aSelector=0x8be49550)
>      at NSApplication.m:2290
> #7  0x0996d98c in -[NSApplication targetForAction:to:from:] (self=0x8a57a984, 
> _cmd=0x29837640, theAction=0x8be49550,
>      theTarget=0x0, sender=0x84fdf904) at NSApplication.m:2275
> #8  0x09b2891c in -[NSMenu update] (self=0x80ffd844, _cmd=0x29837190) at 
> NSMenu.m:1151
> #9  0x09b287f2 in -[NSMenu update] (self=0x81921144, _cmd=0x29805228) at 
> NSMenu.m:1146
> #10 0x09969901 in -[NSApplication run] (self=0x8a57a984, _cmd=0x297fe900) at 
> NSApplication.m:1570
> #11 0x0992466d in NSApplicationMain (argc=1, argv=0xcfbd5c14) at Functions.m:91
> #12 0x1c005ec7 in ___start ()
> #13 0x1c005e42 in _start ()

I may be able to explain that bit. When we update the menu we check 
whether to enable or disable each entry. We only enable it when there is 
a potential target, that is when there is an object in the responder 
chain that responds to the selector of the menu item.
And we do update the menu at each pass through the run loop, that is at 
least on each event that gets handled.

> > On 28 Jan 2012, at 13:17, Sebastian Reitenbach wrote:
> >
> > > Method has v12@0:4@8, selector has @12@0:4@8
> >
> > This looks potentially dangerous.  The caller is expecting the method to return 
> > an object, but the method is a standard IBAction (i.e. returning void).  If the 
> > caller does anything with the return value, then it will likely crash...
> >
> > David
> >
> > -- Sent from my Difference Engine

Have you seen this excellent comic (with notes!) on the Difference Engine:
http://sydneypadua.com/2dgoggles/