[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/