Follow-up Comment #4, bugs #12158 (project gnustep): I'm glad you feel this way and, fortunately, I disagree. :) Our current implementation functions as expected, per Apple/NeXT documentation. See below.
When a template is decoded in the running application, it becomes the custom subclass which the user chose in Gorm. The initWithCoder: method on that custom object must be called so that any addition initlization that the developer wants to happen (not decoding of additional attributes) can be done. This is documented as such. The change you suggest would require that AppKit call the superclass implementation of the initWithCoder: method, which is not correct and could potentially cause GNUstep to skip initialization which is implemented there by developers. I recently updated Gorm's documentation to have a full explaination of all of this, so please review this if you wish. Please also see: http://developer.apple.com/documentation/DeveloperTools/Conceptual/IBTips/Articles/FreqAskedQuests.html The question you are looking for is: "Why does my application crash when I implement initWithCoder (or the above referenced Java Coder constructor) in my custom subclass of a Cocoa widget?" The "class swapper" mentioned there has an analogy in GNUstep as well. When the class is encoded, it must rely on the coding of the class, not your subclass. Later, GJC _______________________________________________________ This item URL is: <http://savannah.gnu.org/bugs/?func=detailitem&item_id=12158> _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ _______________________________________________ Bug-gnustep mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-gnustep
