Dang, that's the problem with being in digest mode. I write a long
response, and then see that three other people have already replied.
Oh well, for what it's worth...
At 12:00am -0700 00-05-10, Palm Developer Forum digest wrote:
>Subject: Re: Symptom of something currupt?
>From: "Richard Burmeister" <[EMAIL PROTECTED]>
>Date: Tue, 9 May 2000 10:52:00 -0500
>X-Message-Number: 21
>
>From: "Ken Krugler" <[EMAIL PROTECTED]>
>
> > >Do you have all three parameters (^1, ^2, and ^3) in your alert?
> > >When you call FrmCustomAlert, don't pass in NULL if your alert
> > >uses ^1, ^2, and ^3. For each unused parameter, pass in a string
> > >containing a single blank.
> >
> > In pre-3.1 versions of the OS, you don't way to pass NULL or ""
> > for any parameter which has a corresponding template (^1, ^2, or
> > ^3) sub-string in the alert text.
>
>I don't understand what you are saying here. I clearly state that you
>should use a string containing a single blank (" ") and you should not use
>NULL. If you check the archives, you'll find an explanation of how passing
>in NULL can cause FrmCustomAlert to miscalculate the length of the message
>string and therefore crash.
Sorry, I wasn't trying to imply that your answer wasn't correct...I
was (too tersely) trying to add the following:
(a) It's a bug that existed in pre-3.1 versions of the OS, but it's
now been fixed. So if your code only runs on 3.1 or later, you don't
need to worry about it.
(b) You only have to worry about not using NULL or "" if that
parameter corresponds to a sub-string which actually exists in your
alert's message. When you said "For each unused parameter, pass in a
string containing a single blank." I thought some readers might be
confused by the meaning of 'unused'.
> > >StrPrintF( msg, "Thank's for registering, %s!\n\nYour code is %s",
> > >name, code );
> > >FrmCustomAlert( GeneralAlert, msg, NULL, NULL );
> > >
> > >Note that, in this case, it is safe to pass in NULL because my
> > >GeneralAlert only contains ^1.
> >
> > This is the kind of thing that will prevent your app from being
> > localizable, for two reasons.
> >
> > a. You've got a hard-coded string in your code.
> >
> > b. The localizers are unable to re-order parameters in the
> > message, which is frequently necessary to get a
> > grammatically correct (or at least reasonable) translation.
> >
>
>The code fragment posted above uses the hard coded string to make the
>FrmCustomAlert example clear. In actual practice, I always used a resource
>for the format string. E.g.,
OK, didn't mean to imply that you wrote bad code :> I was worried
that list readers might take your suggestion literally, without
worrying about localization issues.
>SysCopyStringResource( temp, localFormatString );
>StrPrintF( msg, temp, name, code );
>FrmCustomAlert( GeneralAlert, msg, NULL, NULL );
>
>To localize the message, the localFormatString resource (in this example,
>"Thank's for registering, %s!\n\nYour code is %s") gets translated.
>Therefore, reasons a and b above no longer apply. I'm sorry if simplifying
>the explanation caused any confusion.
Using a string resource solves the first problem, but the localizes
still can't re-order the parameters in the string. For example, in
the string you list above, they couldn't have the code appear first,
followed by the user name, because the call to StrPrintF fixes the
order of parameter substitution. For simple messages this typically
isn't a problem, but it's critical for good localization of more
complex text. On Unix systems a common solution is to use a modified
version of printf that supports numbered parameters in the template
string, for just this reason.
-- Ken
Ken Krugler
TransPac Software, Inc.
<http://www.transpac.com>
+1 530-470-9200
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palmos.com/dev/tech/support/forums/
