Re: Encoding a pointer to an object, not the object itself
Re: Encoding a pointer to an object, not the object itself
- Subject: Re: Encoding a pointer to an object, not the object itself
- From: Keith Blount <email@hidden>
- Date: Sun, 28 Nov 2004 15:24:55 -0800 (PST)
- Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys
Many thanks for your reply.
You are right to assume that the parent folder always
exists before the the document is unarchived. I have
taken your advice and used an identifier to get around
this. Each folder and document is now assigned a
unique int by the project based on an internal
counter. This integer is then archived. Each document
and folder now also stores the identifier of its
parent folder. I have written a method entitled
-(id)objectWithId:(int)idNo to look up the object with
the given ID when needed, so I can find the parent
folder this way when needed, which bypasses all
archiving/pointer problems.
Many thanks again for the suggestion, much
appreciated.
Best regards,
Keith
--- Will Mason <email@hidden> wrote:
> Well, this is just off the top of my head, but your
> design indicates
> that whenever an instance of your Document is
> created the parent folder
> already exists. Therefore, you can be sure that when
> you decode the
> Document object its parentFolder will exist
> somewhere. One idea is to
> encode the name of the parent, or some other
> identifier, then use that
> to look up the existing object at decode time and
> set the pointer that
> way. Another idea is to use the non-keyed encoding
> method
> encodeValueOfObjCType:at: using @encode(id) as the
> type in order to
> store just the pointer. Just make sure that you
> never try to encode the
> object in one process and decode it in another if
> you use this method.
> You'll seg fault.
>
> If it's not guaranteed that the parentFolder already
> exists somewhere
> when the Document object is decoded, then there is
> something wrong with
> your design, and you might want to rethink. For
> example, if
> parentFolder doesn't exist somewhere already, how
> can you hope to
> create a reference to it without decoding the
> parentFolder object at
> the same time as the Document object?
>
> Just a thought,
> Will
>
> --- Keith Blount <email@hidden> wrote:
>
> > Hello,
> >
> > I am probably missing something obvious here, but
> if I
> > am, I can't find any reference to it in any of the
> > books on Cocoa I have nor by searching the
> archives...
> >
> > I have some data that I use as a source for an
> outline
> > view. This uses two classes - a Document class and
> a
> > Folder class. Each document stores a pointer to
> its
> > parent folder. This is just a pointer, like this:
> >
> > - (void)setParentFolder:(Folder *)folder
> > {
> > parentFolder = folder;
> > }
> >
> > It is not retained or anything, as it doesn't
> require
> > it. My problem is, how do I encode and decode a
> > pointer like this in initWithCoder: and
> > encodeWithCoder:?
> >
> > I have to archive and unarchive whenever I drag
> items
> > in the view, and since adding this instance
> variable,
> > things have gone horribly wrong. If I don't retain
> the
> > folder when I decode, the app crashes whenever I
> drag
> > and drop. If I do retain, the dragging slows down
> > horribly - presumably because for every document I
> > drag and drop, the app has to not only encode and
> > decode the document, but also its parent folder.
> >
> > Is there anyway to maintain a simple,
> straightforward
> > pointer to another object between encoding and
> > decoding? I don't see how there is, because the
> > address in memory would change if the actual
> folder
> > item was encoded and decoded (saved and loaded)
> > between session, so the pointer would be
> invalidated
> > then anyway....
> >
> > If anyone can point me in the direction of a
> solution
> > to this, I would be very grateful.
> >
> > Many thanks,
> > Keith
> >
> >
> >
> > __________________________________
> > Do you Yahoo!?
> > Yahoo! Mail - Helps protect you from nasty
> viruses.
> > http://promotions.yahoo.com/new_mail
> > _______________________________________________
> > Do not post admin requests to the list. They will
> be ignored.
> > Cocoa-dev mailing list
> (email@hidden)
> > Help/Unsubscribe/Update your Subscription:
> >
>
> >
> > This email sent to email@hidden
> >
>
>
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden