Some comments on recent posts regarding string resources.
Eric House wrote:
>> > > What is the best way to store strings like that?
>
>> Storing them as resources I think is the best use of
>> your memory, because they will not be taking up part of
>> your precious 32k code segment, and they will only
>> be taking up your valuable heap space when they are
>> loaded & being used. Also it allows for localization
>> (i.e. translation into foriegn languages) if you're into
>> that sort of thing. The downside is that it takes a
>> little extra code and a lot of discipline to put all
>> your string literals into a resource.
>
>Isn't the "extra code" dwarfed by the 8-10 bytes *per string* consumed
>by resource header information? That's why I've been postponing
>moving my user-visible strings into resources. They're already
>#defined in separate human-language-specific .h files for localization
>purposes.
>
>Or does PalmOS have a string list resource like the Mac's 'STR#'?
1. Storing strings in a .h file is better than having them scattered
throughout the code, but it still makes it harder for localizers. In the
future there will be (better) tools for directly editing resources in the
.prc, at which time people who put localizable text in resources (versus
code) will have easily localizable apps.
2. Unless you've got lots of short strings, the percentage overhead from
using resources is minimal. Also this overhead is located in the storage
heap, where there's lots more space than the dynamic heap.
3. There's both a tSTR type (for a single string) and a tSTL type (for a
string list). The tSTR is a a null-terminated C string, while the tSTL is a
prefix string (null terminated) followed by a count (2 bytes) followed by
<count> C strings. The tSTL was originally designed for error strings, and
thus the type in SystemMgr.rh is defined as sysResTErrStrings, but it can
be used for general string lists. The key routine is SysStringByIndex(),
defined in SysUtils.h.
4. A key point is that PalmRez 'knows' about these types, and thus can
perform transliteration of the characters from the MacRoman char set to the
Palm char set. If you're developing on Windows, then this isn't such a big
deal, since the Windows character set is almost the same as Palm's Latin
character set; the only issue might be the numeric space.
For Mac developers this transliteration is critical if you're every going
to have high ascii text in any of these resources. This will definitely be
the case for localization into most other languages, thus embedding strings
in the code, or creating custom resource types that PalmRez doesn't know
about, will both cause problems for localizers.
In addition, custom resource types are hard for localizers to modify,
unless you create appropriate templates for the tool used to modify the
data (e.g. ResEdit TMPLs).
Tom Zerucha wrote:
>You can put multiple strings into one resource (and can even invent your
>own). There is also the:
>
>VoidHand SysFormPointerArrayToStrings(CharPtr c, Int stringCount)
>
>function that unpacks it if you don't want to find the pointers to the
>individual strings yourself.
See #4 above for problems w/inventing custom resource types.
David A. Smith wrote:
>I realize that I could pick some arbitrary character (perhaps NULL
>would even work?) as a delimiter and then write functions to parse out
>the string. I would also need to somehow (programatically) know how
>many strings lived in the resource. Is that what's intended?
This technique of packing multiple strings into a single tSTR has been used
in the past by the rom apps, but is being phased out. The problem is that
most localization tools, when they see that first null, assume they've
reached the end of the string and thus don't display the rest (or show it
as hex). Even using a printable character as a delimiter between substrings
makes it harder for the localizer - inevitably they'll accidentally delete
one of these special chars, and thus create an invalid resource.
-- Ken
Ken Krugler
TransPac Software, Inc.
<http://www.transpac.com>
+1 530-470-9200 (direct) +1 408-261-7550 (main)
