macOS odd table behavior

[Sydde]

I was working on a rather complicated NSTable subclass, and everything was going just fine, then all of a sudden the program just plain failed. I traced the failure to the autorelease of a table column data cell (an NSTextFieldCell subclass that my code had put there as part of the awaking process). I put in an -autorelease override that logged and found that the cell was getting autorelease messages whenever I clicked on it (while selecting the row), moved the mouse over it in the selected row, selected it for editing and whenever a character was typed into it. When it exited editing, the log would show that the autorelease pool had received a -validateEditing: message that it could not understand.

All this was supremely aggravating. I was able to get past it by setting -fobjc-gc (garbage collection supported) but I just cannot understand why it would be fine one minute, then a quick build and everything is messed up. I suppose I could blame the cat for walking on the keyboard while I was out of the room, but then I would expect some sort of build errors or warnings.

Has anyone seen this kind of thing?

 

[lee1210]

This will be supremely unhelpful for this problem, but I'd suggest source control in the future so you can see what changed from a known-good version to a broken version.

However, with memory problems often the last change isn't the culprit. You've had problems for a long time, and the last change is just exploiting the problem.

Why not override retain and release as well as autorelease, taking care to pass the message up to your superclass. You could then break on your overriding methods in the debugger and see what's passing these, perhaps erroneously.

Good luck if you decide to dive back in to debugging the non-GC version.

-Lee

 

[Sydde]

Well, that was instructive. I did in fact put in some overrides and examined what goes on in NSTable. Apparently, when one clicks on a row, the table goes through a lot of activity between the field editor, the cell (NSActionCell) and the table which involves dozens of autoreleases and retains that eventually ends with the table making a copy of the cell before it finally passes away. There must be a good reason for all that activity that eludes me.

My mistake was putting a strong reference into the cell. This can be done if one overrides -copyWithZone: to retain the strong reference before -dealloc makes the object go away, but mostly I learned that one should view cells in larger views (like tables, forms or matrices) as ephemeral objects that should not contain strong references.

 

[lee1210]

After fixing the strong reference in your copyWithZone: is everything kosher? That's what I gathered from your post, but I wasn't sure. I'm not familiar with GUI stuff in Cocoa, but i'm glad that this was helpful if you did work out the problem.

-Lee

 

[Sydde]

No, actually, I just turned it into a weak reference (took out the troublesome -release in the -dealloc and will manage the object in question differently). I wanted a compact setup where releasing a column would release everything at once, but it would be a rare enough event that one extra step would be the easier way to handle the situation.

Thanks for pushing me to resolve that. Relying on garbage collection just seems like such a cop-out to me.