[bugs #12158] Custom views in gorm and NSCoding problem

[Gregory John Casamento]

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/