At 09:25 AM 4/30/2008, you wrote:
> > I am trying to save a Folderitem to a .plist. I use GetSaveInfo to
> > get the string. Its encoding at that time is Nil.
>
>This is correct. It's binary data, not text.
See below.
> > I store it in a .plist dictionary (I use that popular PLIST class
> that circulates).
>
>This is a mistake. The Plist class almost certainly expects text,
>not binary data.
Right, I was sniffing this out along those lines.
When I started programming years ago, I always wondered in a very
common-sensical way "why to people tend to put non-textual data into
strings" when looking at example code etc. I now know why they did it
back then, but nowadays there's no reason for it really.
Isn't that a very fundamental mistake that is propagated by functions
like GetSaveInfo? I mean, it specifically says in the docs "don't
fiddle with the string". Although YOU MAY NOT, something else will,
as we see. I figure RB uses that datatype because there is nothing
else to use - unless you count a MemoryBlock, but that isn't written
easily into a plist or whatever, which almost certainly is the intention.
It's like that RB function gives you a nuclear bomb, armed and ready
to ignite, and they say "here you go, just don't touch the red
button". Wouldn't it have been better for RB to Base64 it themselves,
since the only purpose of the string is to be created by GetSaveInfo
and read by GetRelative?
Wait.. I know the answer: sometimes it's not necessary, so don't bulk
up the function unnecessarily. Leave it to the user to add the
flexibility. But then again, practically the ONLY purpose of
GetSaveInfo (as revealed by the name) is to store it as text and NOT
binary data. I still figure that the "secret text format" RB uses in
GetSaveInfo should be basee64'd in the first place, that would be
logical. if not, at the very least, this should be printed in the
manual that it's binary data. I mean, I knew that from osmosis and by
looking at the string. Oh well... that's why they hired Norman and Thom!
Speaking of which, I always have thought that companies should have
an engineer that performs like a "user engineer", sort of like a
ombudsman behaves with a newspaper, only more active.
This engineer would specialize in customer contact, and be able to
actually implement all these small little things that make a huge
difference (in sum total). He wouldn't work on large implementations
or features, just the small ones and the cleanup.
Parallel to that idea, is the ability to segment the IDE/app (that
is, RB) into segments where this "user engineer" can change one part
of the code structure yet not have to build an entire single-file
application (and jeopardize other unrelated things). I think the
Rapid-Release thing is great, but I always envision an even better system.
>No, having an encoding doesn't corrupt the string; it was corrupted
>by trying to treat it as text. It may happen to contain line breaks
>and other things that make a mess of the plist file.
>FolderItem.GetRelative expects binary data, and ignores any encoding
>set on the string; it would work fine if the bytes were right -- but
>the bytes by this point are wrong.
Right, ok. Now that I'm complaining... =) Isn't GetRelative a real
bad name for this function? Most of the time I'm using GetSaveInfo to
give me absolute information. Tying it in with a FolderItem is
unnecessary with that. Should be called RetrieveSaveInfo() IMO. Also,
the docs are unclear - it says the host FolderItem of GetRelative is
ignored if the GetSaveInfo-generated string is absolute, but the host
FolderItem can't be Nil of course, so it's not COMPELTELY ignored.
Bad implementation. I'm glad it exists though.
>The right solution, as Norman suggested, is to EncodeBase64 your save
>info (converting it from binary to text data) before stuffing it into
>your plist. And then when you get it out, DecodeBase64 to get the
>binary data back.
Makes sense. This cries out for a wrapper function! =)
Garth Hjelte
Sampler User
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>
Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>
|