Re: NSClassSwapper leaving dangling pointers?

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 <address@hidden>:

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 <address@hidden> 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 <address@hidden> 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 <address@hidden> 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

From:	Gregory Casamento
Subject:	Re: NSClassSwapper leaving dangling pointers?
Date:	Wed, 26 Jun 2013 07:36:58 -0400