Fred, NSClassSwapper is only unarchives for those objects which have custom class object replacements. So it should only replace the cells of those objects not for all objects in the archive.
As far as the menu item using itself as a target that I am not sure of. I remember seeing this myself. I'll investigate further and see if I can determine why. GC On Wednesday, June 26, 2013, Fred Kiefer wrote: > I am currently on holidays with only my iPad and limited connectivity. > That's why I may be wrong on a few things. Still I think that the class > swapper does stuff it should not be doing. It seems to replace all cell > objects not just the cells belonging to the controler it is currently > decoding. And it even replaces these cells when they are already of the > correct subclass. Both things, if valid, need to be changed. > > What I don't understand is why a menu item would use its cell as the > target. Or is the main cell of a popup button being used as the target of > its menu items? Only the inspection of the NIB file could explain this. The > later could explain our problem as we replace an object that has external > references to it. > > Fred > > On the road > > Am 26.06.2013 um 07:45 schrieb Gregory Casamento > <[email protected]<javascript:_e({}, 'cvml', > '[email protected]');> > >: > > Upon further examination, I'm not sure that Fred's concern is valid. The > reason the cell contents are not copied is because they don't have to be: > > result = [[newCellClass alloc] initWithCoder: coder]; > > The above line in the method -(id)unarchiver:didDecodeObject: unarchives > the proper attributes into the new instance and replaces the old instance > of the cell. > > > On Wed, Jun 26, 2013 at 1:35 AM, Gregory Casamento < > [email protected]> wrote: > > Lubos, > > I'm not sure why you're saying it should only be used for looking up the > name. What leads you to the conclusion that this is all it's used for. > When I wrote it I did many backtraces to determine how it worked. > > If you have known object A and custom class B. "Known" classes are classes > which IB knows about (e.g. Cocoa classes) and can archive. A is what is > actually archived in the .nib file because that is what Interface Builder > can instantiate and save, but in the data structures which are saved in the > nib, there is a map which indicates that object A should be replace by an > instance of custom class B. The way this is indicated by the user is when > you select the custom class in the class inspector in IB. > > NSClassSwapper is certainly doing what it is supposed to be doing in this > case. The only fault, I believe is what Fred pointed out in an earlier > email. The cell contents and settings are not being copied and, perhaps, > they should be. > > Anyway, just adding my 0.02 to the conversation. > > GC > > > On Tue, Jun 25, 2013 at 7:48 PM, Gregory Casamento < > [email protected]> wrote: > > Wow, I really need to look into this immediately. NSClassSwapper does > what its name suggests. It determines the custom class for a given object > and instantiates it. > > It shouldn't create an object then destroy it immediately. > > > On Tue, Jun 25, 2013 at 2:57 PM, Luboš Doležel <[email protected]> wrote: > > Hi, > > I've contacted the author and it seems it doesn't serve any purpose at > all, as is. > > "Sounds like one of the character encoding popups. The actual contents > of the menu are built dynamically at runtime." > > Which sounds logical, given that the item's description is "dummy" (and > the replacement class is "TUEncodingPopUp". > > Either way, GNUstep should somehow support it. What I don't understand > why isn't NSClassSwapper used only to determine the real class name. Why > first create a different object only to destroy it moments later? > > I also couldn't find out why -initWithCoder: on the new object doesn't > replace the child objects as well - which I'd guess would mitigate the > proble > > -- Gregory Casamento Open Logic Corporation, Principal Consultant yahoo/skype: greg_casamento, aol: gjcasa (240)274-9630 (Cell) http://www.gnustep.org http://heronsperch.blogspot.com
_______________________________________________ Gnustep-dev mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnustep-dev
