bug-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Stefan Urbanek
Subject: [bugs #12158] Custom views in gorm and NSCoding problem
Date: Sun, 27 Feb 2005 08:56:32 +0000
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040804

Follow-up Comment #3, bugs #12158 (project gnustep):

I do not think that custom subclasses which are selected using the custom
class inspector should never encode additional data. You are right, that Gorm
cannot know about this data. And AFAIK, the Gorm encodes only a "placeholder"
for this custom class. Then it is logical, when Gorm does not encode the
class, it should not decode it. If you have a palette it is different: you
encode then object and then decode it.

I found this accidentaly by running dkautogen to all my .h files in an
application. This resuled in autogenerated encoding/decoding methods in each
class. And that resulted in broken application.

Also if I have custom class with custom encoding, then I see no reason of
puttig it into a palette to be able to use it in Gorm if I do not want to use
the custom variables/encoding/decoding of the class. It is said, that the
custom view class should implement initWithFrame:. That should be enough to
set up default values for the view. If I would like to set more, then I would
setup a palette.

However, again: if it is not encoded, then do not decode it. And the custom
class is not encoded in the archive.



    _______________________________________________________

This item URL is:

  <http://savannah.gnu.org/bugs/?func=detailitem&item_id=12158>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/





reply via email to

[Prev in Thread] Current Thread [Next in Thread]