Re: [Pyobjc-dev] problems building editable tableviews

[<bb...@ma...>]

On Thursday, October 17, 2002, at 12:12 PM, Aaron Swartz wrote:
> Hi there,
>
> I've got a PyObjC app that has a table view working great, but as soon 
> as I add a definition for 
> tableView_setObjectValue_forTableColumn_row_, my app crashes as soon 
> as try to edit one of the rows and before my Python function gets 
> called. Here's the stacktrace:

Did you declare the selector signature for that method?

I.e. after you declare the function on your Python object, add this:

         tableView_setObjectValue_forTableColumn_row_ = 
objc.selector(tableView_setObjectValue_forTableColumn_row_, 
signature='v@:@@@i')

Annoyingly confusing, I know.  We are working out how to make this 
easier.  The basic problem is that you need to tell the Obj-C runtime 
about the types accepted by the method.  In this case, v@:@@@i means -- 
returns void, has arguments of type (id self), (SEL _cmd), id, id, id, 
int.

I'd be willing to bet you were editing row 4 (or maybe 1)?

That objc_msgSend() died is likely because it tried to treat the int 
argument as an object of type (id) -- the method dispatch code in 
Python tried to send it a message to figure out if it needed to convert 
it as it passes across the bridge.

>
> Date/Time:  2002-10-17 10:40:30 -0500
> OS Version: 10.2.1 (Build 6D52)
> Host:       slithy.local.
>
> Command:    Memesh
> PID:        10833
>
> Exception:  EXC_BAD_ACCESS (0x0001)
> Codes:      KERN_PROTECTION_FAILURE (0x0002) at 0x00000004
>
> Thread 0 Crashed:
>  #0   0x9068ba4c in objc_msgSend
>  #1   0x00508694 in pythonify_c_value (objc_support.m:566)
>  #2   0x00574598 in meth_imp_211 (register.m:18542)
>  #3   0x932d744c in -[NSTableView textDidEndEditing:]
> .....


> Thanks for any help you can provide.

Hopefully, that'll "just work".

> Also, what's the policy on threading? I expect my app to do some 
> intense networking and indexing, and I don't want it to become 
> unresponsive while it's doing that. I tried importing "threading", but 
> when I tried to do something in another thread, it spewed out 
> thousands of no autoreleasepool -- leaking! messages.

I haven't looked -- Ronald?

But the problem you describe is because the threads don't have an 
NSAutoreleasePool when they are created, but you are causing Obj-C 
activity in that thread and, as a result, are causing objects to be 
created and autoreleased.  When autoreleased, but no pool has been 
created, you'll see this error.

(Try creating a default Foundation tool object, open the main, delete 
the lines referring to the autorelease pool and do: NSLog(@"%@ %@", 
@"Hello, World!", [NSCalendarDate date]); and you'll see the same 
messages.)

So -- when the thread is created, create an autorelease pool for that 
thread.  From the thread, just alloc/init a new autorelease pool.

As long as the thread is pure python, you shouldn't see this message.

>
> Thanks again for such an awesome tool!

Your welcome -- it makes me very happy to know that people are actually 
using it!

b.bum