[MonoTouch] Still IntPtr Constructor issues

Wed Dec 7 17:24:16 EST 2011

Thanks Rolf! I tried that! Here is the result. But I'm none wiser! It is supposed to relayout, I can relayout, but why does it go for the IntPtr ctor? What is thie "_createPreparedCellForGlobalRow" about?
My "fix" is: if the IntPtr ctor is called, I set a bool to indicate the cell if in invalid state. When dequeing cells, I check if the cell is NULL or that bool is set. In both cases I create a new instance of the cell and everything works fine. But still I would like to know if somebody can make sense from the debugger output:

#0  0x933b583e in __psynch_cvwait ()
#1  0x9a6aae21 in _pthread_cond_wait ()
#2  0x9a65b42c in pthread_cond_wait$UNIX2003 ()
#3  0x00104188 in suspend_current () at debugger-agent.c:2375
#4  0x00105da6 in process_event (event=EVENT_KIND_BREAKPOINT, arg=0xa1ac33c, il_offset=0, ctx=0xbfffca08, events=0x0, suspend_policy=2) at debugger-agent.c:3017
#5  0x001080c4 in process_breakpoint_inner (tls=0x9c78f10, ctx=0xbfffca08) at debugger-agent.c:3837
#6  0x00108199 in process_breakpoint () at debugger-agent.c:3855
#7  0xbfffc6c8 in ?? ()
#8  0x10a7e06f in ?? ()
#9  0x00011aef in mono_jit_runtime_invoke (method=0xa1ac33c, obj=0x9ae7cc0, params=0xbfffcb60, exc=0x0) at mini.c:5770
#10 0x0022011a in mono_runtime_invoke (method=0xa1ac33c, obj=0x9ae7cc0, params=0xbfffcb60, exc=0x0) at object.c:2757
#11 0x002ee535 in monotouch_trampoline ()
#12 0x0248e852 in -[UITableViewCell setSelected:] ()
#13 0x0234044d in -[UITableView(UITableViewInternal) _createPreparedCellForGlobalRow:withIndexPath:] ()
#14 0x02340589 in -[UITableView(UITableViewInternal) _createPreparedCellForGlobalRow:] ()
#15 0x0232bdfd in -[UITableView(_UITableViewPrivate) _updateVisibleCellsNow:] ()
#16 0x0233a851 in -[UITableView layoutSubviews] ()
#17 0x022e5322 in -[UIView(CALayerDelegate) layoutSublayersOfLayer:] ()
#18 0x012d8e72 in -[NSObject performSelector:withObject:] ()
#19 0x0427592d in -[CALayer layoutSublayers] ()
#20 0x0427f827 in CA::Layer::layout_if_needed ()
#21 0x04205fa7 in CA::Context::commit_transaction ()
#22 0x04207ea6 in CA::Transaction::commit ()
#23 0x04207580 in CA::Transaction::observer_callback ()
#24 0x012ab9ce in __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ ()
#25 0x01242670 in __CFRunLoopDoObservers ()
#26 0x0120e4f6 in __CFRunLoopRun ()
#27 0x0120ddb4 in CFRunLoopRunSpecific ()
#28 0x0120dccb in CFRunLoopRunInMode ()
#29 0x0489f879 in GSEventRunModal ()
#30 0x0489f93e in GSEventRun ()
#31 0x022a6a9b in UIApplicationMain ()
#32 0x0cfdcb0d in ?? ()
#33 0x0cfdb2f0 in ?? ()
#34 0x0cfdafe8 in ?? ()
#35 0x0cfdb13e in ?? ()
#36 0x00011aef in mono_jit_runtime_invoke (method=0xa9e5e2c, obj=0x0, params=0xbffff158, exc=0x0) at mini.c:5770
#37 0x0022011a in mono_runtime_invoke (method=0xa9e5e2c, obj=0x0, params=0xbffff158, exc=0x0) at object.c:2757
#38 0x00222e51 in mono_runtime_exec_main (method=0xa9e5e2c, args=0xcd52960, exc=0x0) at object.c:3940
#39 0x00222061 in mono_runtime_run_main (method=0xa9e5e2c, argc=0, argv=0xbffff300, exc=0x0) at object.c:3562
#40 0x000ad6df in mono_jit_exec (domain=0x9a6fe00, assembly=0x997d1c0, argc=1, argv=0xbffff2fc) at driver.c:1102
#41 0x002f41ca in main ()

René

Am 07.12.2011 um 23:09 schrieb Rolf Bjarne Kvinge:

> Hi,
> 
> On Wed, Dec 7, 2011 at 9:03 PM, Rene Ruppert <rene.ruppert at googlemail.com> wrote:
> 
> And there's one more thing I would like to add: If I put a breakpoint in SetSelected() of the cell I can see that it is called constantly (even for cells constructed without using the IntPtr) but the interesting thing is that the call stack is always pretty small and does not show where the call is coming from.
> It contains these two lines and that's it:
> 
> MonoTouch.UIKit.UIApplication.Main (args={string[0]}, principalClassName="UIApplicationMain", delegateClassName="AppDelegateIPad") in 
> 
> /Developer/MonoTouch/Source/monotouch/src/UIKit/UIApplication.cs:29
> Browser.Application.Main (args={string[0]}) in /Users/Krumelur/Documents/Develop/.../Main.cs:15
> 
> The problem here is that native (objc) frames aren't shown in the managed stack trace.
> 
> To get native frames you can attach gdb while at the breakpoint. Get the pid of the application (printed to the application output in MonoDevelop when the app starts), and execute in a terminal:
> 
> gdb program <pid>
> (gdb) bt
> <you should now get a stack trace with native frames>
> (gdb) quit
> 
> Unfortunately the native stack trace will not have managed frames  (1).
> 
> Rolf
> 
> (1) You can get information for managed frames in gdb, look at mono_pmip here: http://www.mono-project.com/Debugging#Debugging_with_GDB
> 
>  
> So something seems to trigger it magically.
> 
> René
> 
> Am 07.12.2011 um 20:55 schrieb Rene Ruppert:
> 
>> Hi,
>> 
>> I'm still struggling with the IntPtr Constructor issue I started on SO.
>> I got a bit further meanwhile.
>> 
>> The case is: I'm subclassing UITableViewCell and do not provide the IntPtr:ctor.
>> 
>> By adding the ctor and breaking in there I figured out what ObjC wants my class to do: it is calling void SetSelected ( bool selected, bool animated ).
>> 
>> This means "something" wants to select my cell. I looked through my code and found exactly ONE place where I call SelectRow(). I commented that out and STILL it goes through the ctor and to SetSelected().
>> 
>> What are my options now? Does UITableViewCell maybe always require the IntPtr ctor?
>> What could possibly still select a row in a UITableView besides SelectRow()?
>> 
>> René
>> 
> 
> 
> _______________________________________________
> MonoTouch mailing list
> MonoTouch at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/monotouch
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/monotouch/attachments/20111207/a7765ec8/attachment.html 