Our application had a crash when deallocating a clipView, because its nextKeyView pointed to an object that had already been freed. On carefully reviewing the code, I discovered that the system is designed such that each view can have _multiple_ next and previous key views.
I understand why a view could have multiple _previous_ key views (since it's possible to have several other views all pointing to it as their nextKeyView). But I don't believe a view should ever have more than one _next_ key view. I've checked in a change to NSView.m (r30088) that fixes this problem (part of the issue for us turned out to be caused by ivars being zeroed out at the wrong point during nib loading). But it appears to me that the code could be cleaned up and simplified quite a bit if everyone agrees with my assertion that a view should only have one (or zero) nextKeyView. To begin with, the _nextKeyView ivar could be turned into a direct pointer to the next key view rather than a GSIArray. Also, the code is not well encapsulated right now, as it makes direct changes to ivars of other objects. Does anyone see any reason not to change nextKeyView to a single object? Would someone familiar with that code like to make the change? (In particular, I'm unsure whether there may be other classes besides NSView that might be impacted…) Doug Simons TestPlant, Inc. P.S. I tried to send this twice before but it was rejected, so I'm trying this from a different account. Any ideas why my email would be "delayed" with this message: "eggs.gnu.org:451 Could not complete sender verify callout" ? "Be kind whenever possible. It is always possible." - Dalai Lama _______________________________________________ Gnustep-dev mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnustep-dev
