Am 26.06.2013 um 13:36 schrieb Gregory Casamento <[email protected]>:
> 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. I think it replaces all cells while it is active, for a popup button that would include the cells of the menu, but I may be wrong here. You see the code, I work from memory. > 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. > Not itself, the cell of the popup gets used as the target, Wolfgang Lux cleared this one up already. > > 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]>: > >> 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
_______________________________________________ Gnustep-dev mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnustep-dev
