bugGNUstep - Bugs: bug #12158, Custom views in gorm and NSCoding...

Group
 
 

bug #12158: Custom views in gorm and NSCoding problem

Submitter:  Stefan Urbanek <stefanu>
Submitted:  Sun 27 Feb 2005 12:13:11 AM UTC
   
 
Category:  Gorm Severity:  2 - Minor
Item Group:  Bug Status:  Invalid
Privacy:  Public Assigned to:  gcasa
Open/Closed:  Closed
* Mandatory Fields

Add a New Comment Rich Markup
   

Sun 27 Feb 2005 02:32:17 PM UTC, comment #4: 

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

Gregory John Casamento <gcasa>
Group administrator
Sun 27 Feb 2005 08:56:31 AM UTC, comment #3: 

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.


Stefan Urbanek <stefanu>
Group Member
Sun 27 Feb 2005 02:33:45 AM UTC, comment #2: 

Another way to approach this is to use the "CustomView" which doesn't invoke initWithCoder: when it's unarchived.   The only method which is called in this case is initWithFrame: (per docs).  

The best way to do this, if you need to be able to inspect the extra attributes on an instance of the new class is to create a palette, as described before.  Palettes allow you to write inspectors and editors which can allow the user to manage the extra attributes.

If you have a Mac, you will find that the same behavior is apparent there as well, if you use non-keyed coding. :)

Gorm, and IB, use proxy objects to facilitate the use of custom classes which they don't know about.   Some of this is covered in the Gorm documentation.

Gregory John Casamento <gcasa>
Group administrator
Sun 27 Feb 2005 02:23:10 AM UTC, comment #1: 

This is not a bug.

Custom subclasses which are selected using the custom class inspector should never encode additional data since Gorm cannot know about this data.  The best way to get Gorm to encode extra data for a subclass, if that is what is required, is to add that class to a palette from which Gorm can then add instances of the class to .gorm files.

See palettetest under dev-apps/test for an example of how to do this.

Gregory John Casamento <gcasa>
Group administrator
Sun 27 Feb 2005 12:13:11 AM UTC, original submission:  

When a custom class is used in Gorm and implements the NSCoding protocol, NSBundle additions fails to load the .gorm file because it tries to initWithCoder: the custom class. Problem is, that the custom subclass object is not encoded in the archive, of course - the structure of the custom class is not known to Gorm.

Stefan Urbanek <stefanu>
Group Member

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

CC list is empty

 

There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

Only logged-in users can vote.

 

Follow 3 latest changes.

Date Changed by Updated Field Previous Value => Replaced by
2005-02-27 gcasa StatusNone Invalid
    Assigned toNone gcasa
    Open/ClosedOpen Closed

Back to the top

Powered by Savane 3.13-02a9.
Corresponding source code