Re: NSClassSwapper leaving dangling pointers?

[Gregory Casamento]

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
problem too.

Luboš

On 06/24/2013 09:07 PM, Fred Kiefer wrote:
> This backtraces finally helped me understand what goes on here a bit
> better, at least I hope so.
>
> NSClassSwapper not only replaces a specific object, it also registers
> itself as the delegate of the decoder to be able to replace the cells
> used by that object. This happens here and the decoded cell gets
> replaced by a newly created cell without transfering any of the
> already set values.
>
> What I still don't understand is why the menu item uses its menu cell
> as the target. This ould be another difference to the GNUstep
> implementation. Could you please try to find out what the used action
> is?
>
> At the moment I still don't have an idea how we could work around
> this issue. We should try to find out more about it.
>
> Fred
>
> On the road
>
> Am 24.06.2013 um 11:49 schrieb Luboš Doležel <address@hidden>:
>
>> Sorry for the spam, I have another backtraces providing a clear
>> picture, alhough they seem to be slightly different from the ones
>> before.
>>
>> You can see an object being set as a target, then deallocated and
>> then used (with SIGSEGV).
>>
>> Luboš
>>
>>
>> On Mon, 24 Jun 2013 10:21:18 +0200, Luboš Doležel wrote:
>>> What I forgot to add:
>>>
>>> Until gnustep-gui supports resource directory names like
>>> "en.lproj", you have to symlink English.lproj->en.lproj to make
>>> it work (GNUstep bug #36764). This bug also prevents apps from
>>> working when mounted directly from a .dmg file via my FUSE
>>> module, since the mounts are read-only.
>>>
>>> Lubos
>>>
>>> On Mon, 24 Jun 2013 09:52:51 +0200, Luboš Doležel wrote:
>>>> Hi,
>>>>
>>>> great! Feel free to contact me via Jabber (same as mail
>>>> address), should you run into any issues.
>>>>
>>>> Attached is the backtrace leading up to NSClassSwapper, as
>>>> Germán requested.
>>>>
>>>> Lubos
>>>
>> <darling-unarchiver2.txt>
>> _______________________________________________ Gnustep-dev mailing
>> list address@hidden
>> https://lists.gnu.org/mailman/listinfo/gnustep-dev
>

--
Luboš Doležel

_______________________________________________
Gnustep-dev mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/gnustep-dev

--
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

--
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

--
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