[MacRuby-devel] Problems with return code from sheet (possible regression)

[Michael Winterstein]

It seems to be working in 2761, thanks.  For a little while none of  
those calls were getting through (apparently being sent to  
drb.method_missing) so I couldn't check if it was working.  'RunModal'  
is a workaround for that specific call, too.  I'm also looking into  
SL's new way of using sheets, with a completion handler.

Michael
On Oct 6, 2009, at 4:57 PM, Laurent Sansonetti wrote:

> FYI, the problem should (in theory) be fixed in r2741.
>
> Laurent
>
> On Oct 6, 2009, at 1:28 PM, Laurent Sansonetti wrote:
>
>> Hi Michael,
>>
>> It's actually a well-known bug. MacRuby trunk doesn't honor the  
>> sel_of_type BridgeSupport attribute, therefore your sheet callback  
>> is registered to the runtime with the default signature (where all  
>> arguments and return value are Objective-C objects), and later it  
>> fails to convert the returnCode argument (in this backtrace, 0x1)  
>> as an Objective-C object.
>>
>> Laurent
>>
>> On Oct 6, 2009, at 12:58 PM, Michael Winterstein wrote:
>>
>>> I seem to have run into nearly the same problem that I had a while  
>>> back, in this ticket:
>>> http://www.macruby.org/trac/ticket/221
>>>
>>> I haven't filed it yet this time since last time it turned out to  
>>> be already fixed, but I'm not certain that's the case now.  At any  
>>> rate, it's being handled by different functions.
>>> The same thing is happening - the return code being passed to my  
>>> delegate (from [NSApplication endSheet:returnCode]) isn't being  
>>> treated as the NSInteger it ought to be.  At least I think so.   
>>> Here's the trace, and you can see that the value 1(NSOKButton) is  
>>> being treated as id, causing problems (0/NSCancelButton doesn't  
>>> crash as it's a special case) :
>>>
>>> Program received signal:  “EXC_BAD_ACCESS”.
>>> (gdb) bt
>>> #0  rb_ocid_to_rval [inlined] () at /Users/parzival/devo/buried/ 
>>> MacRuby/trunk/include/ruby/ruby.h:1252
>>> #1  0x0000000100130161 in rb_vm_ocval_to_rval (ocval=0x1) at  
>>> compiler.cpp:6155
>>> #2  0x000000010110537c in ?? ()
>>> #3  0x00007fff820c29f9 in -[NSApplication endSheet:returnCode:] ()
>>> #4  0x00007fff81fd523e in -[NSApplication sendAction:to:from:] ()
>>> #5  0x00007fff81fd519d in -[NSControl sendAction:to:] ()
>>> #6  0x00007fff8206068b in -[NSCell  
>>> trackMouse:inRect:ofView:untilMouseUp:] ()
>>> #7  0x00007fff820911a3 in -[NSButtonCell  
>>> trackMouse:inRect:ofView:untilMouseUp:] ()
>>> #8  0x00007fff8205f135 in -[NSControl mouseDown:] ()
>>> #9  0x00007fff81f79967 in -[NSWindow sendEvent:] ()
>>> #10 0x00007fff81eaf122 in -[NSApplication sendEvent:] ()
>>> #11 0x00007fff81e45acc in -[NSApplication run] ()
>>> #12 0x00007fff81e3e798 in NSApplicationMain ()
>>>
>>> Attached are a few files as a test case, an NSWindowController  
>>> subclass and MainMenu.nib that can be dropped into a  new project  
>>> to check this if anyone wants to.  I recall when I first had this  
>>> problem that I could see what the change was, but unfortunately  
>>> I've forgotten that now.
>>> <Testfiles.zip>
>>>
>>>
>>>
>>> _______________________________________________
>>> MacRuby-devel mailing list
>>> MacRuby-devel at lists.macosforge.org
>>> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
>>
>> _______________________________________________
>> MacRuby-devel mailing list
>> MacRuby-devel at lists.macosforge.org
>> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
>
> _______________________________________________
> MacRuby-devel mailing list
> MacRuby-devel at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel