On Thu, Dec 8, 2011 at 1:52 AM, Rene Ruppert <[email protected]>wrote:
> But isn't that then,like Miguel said, an issue of Monotouch? Shouldn't it > keep a reference? > I have not seen a single MT example so far tat keeps explicit references > to table view cells. Are they all wrong? > It's actually quite a tricky subject, we've tried a lot of possible solutions and we've come to the conclusion that it's virtually impossible to make it perfect (which is that managed code should not need to hold objects alive manually and at the same time no objects should be leaked). We have improved some scenarios (included in the current v5.1.1 beta, but it has to be enabled manually), and we're working on documentation explaining exactly what has been improved. Returning to your particular problem: in theory it should work if you subclass UITableViewCell (which you do) - in which case the object is kept alive while native code has a ref. Unfortunately objc might not keep a ref in all cases (for instance look at assign setter semantics here: http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/ObjectiveC/Chapters/ocProperties.html#//apple_ref/doc/uid/TP30001163-CH17-SW2), which I suspect is what's happening to you. It is however hard to find the exact cause without a sample we can run ourselves. Keeping an explicit ref to table view cells is a pretty easy workaround (and it doesn't suffer from the undefined behavior adding the IntPtr ctor would have). The problem is of course to know when to remove the explicit ref - but in my experience you don't end up with that many table view cell instances if you reuse them (and just release the explicit ref when the corresponding view is unloaded). I hope this helps, Rolf
_______________________________________________ MonoTouch mailing list [email protected] http://lists.ximian.com/mailman/listinfo/monotouch
