gnustep-dev
[Top][All Lists]
Advanced

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

Re: New GWorkspace feature (fwd)


From: Gregory John Casamento
Subject: Re: New GWorkspace feature (fwd)
Date: Sat, 11 Oct 2003 12:02:10 -0700 (PDT)

Enrico,

--- Enrico Sersale <address@hidden> wrote:
> On 2003-10-11 20:13:01 +0300 Gregory John Casamento
> <address@hidden> wrote:
> 
> >> ...
> >> I'm writing a previewer for the IBViewPboardType that seems to work with 
> >> many
> >> kind of objects copyed from a Gorm window. But I've noticed a problem:
> >> 
> >> 1) I create a NSBox in Gorm with a CustomView in it.
> >> 2) now I cut or copy the NSBox with its content.
> >> 3) then I paste it on the GWorkspace shelf or in a Gorm window.
> >> 
> >> In both the cases, (Gorm window or GWorkspace shelf) I get a "decoded nil
> >> class" or "expected object and got unsigned int" exception from 
> >> NSUnarchiver.
> >> So, I think that the bug is in Gorm, where the pasteboard is created.
> >> Before committing, I'd want to know if this is a known Gorm problem and if
> 
> >> it
> >> will be fixed soon.
> >> 
> > 
> > I believe I might know what the issue is.
> > If your most recent version of GWorkspace has been checked into CVS I would
> be
> > happy to start working on a solution to fix this.
> > 
> > Thanks, GJC
> 
> Ok, I've just committed this stuff. But you need to enable the
> IBViewPboardType previewer uncommenting:
>    return NO;
> at the beginning of -displayData:ofType: in the implementation of the
> IBViewPboardViewer that is in
> ContentViewers/PasteboardViewer/PasteboardViewer.m.
> But you can reproduce the problem, without using GWorkspace, pasting the
> object in the same Gorm window where you copied the object from.
> 
> Ciao,
> Enrico
> 

I don't think this is a bug in Gorm.  

The pasteboard uses NSArchiver and NSUnarchiver to work.

I believe that this is due to the fact that the Custom View and other custom
classes Templates use features of the archiver to transform themselves into the
intended custom class when they are unarchived in the running application for
which they were intended to be used.   This is the correct thing for them to do
since, in the running program, the necessary class will be linked in and
present.   For instance:

If you specify a custom view to be an instance of the class MyView.   This
information is specially encoded in the .gorm file so that when it is
unarchived the CustomView "transforms" into the actual class which was
specified.   This is true of other custom classes as well. 

This mechanism is well tested, works, and has been bug free for several months
now.  If you try to unarchive a .gorm into a program which does not have those
classes defined you will get the "decoded nil class" error.   I believe that
the problem lies in what GWorkspace is trying to do here.

We can have a look to see if there's anything which can be done in GWorkspace
to make this work as it does sound like an interesting feature.

Thanks, GJC

=====
Gregory John Casamento
-- bheron on #gnustep, #linuxstep, & #gormtalk ----------------
Please sign the petition against software patents at:
http://www.petitiononline.com/pasp01/petition.html
--- Main Developer of Gorm (featured in April Linux Journal) ---

__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com




reply via email to

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