true, although that's a very inefficient way to implement it, with respect
to CPU cycles (and battery usage).

i've written a generic formatting engine before, on the Win32 platform.  it
is extendable, can work against fixed length buffers, or dynamic length
buffers (via a callback), and is localization friendly (eg, "{s0}{s1}"
instead of "%s%s" - this means if some language needs the two strings
swapped, you don't have to change any code to do so, since the format tag
includes the index of the argument).  eventually i'll work on porting it to
the Palm platform (eventually i'll need it for my own freeware app anyway).
OTOH, it did require that all arguments were 32-bit, and used C++ in
validate the supported types (without adding any code bytes in the
process!).

sorry, i can't give any timeframe on it, though.


----- Original Message -----
From: "William F. Weiher III" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, January 06, 2000 7:58 AM
Subject: RE: StrPrintF


> If StrPrintF would accept a NULL destination but still return the correct
> count of characters generated, this would be easy to implement.
> Unfutunately, the current code does a StrLen on the string generated to
get
> the length). Just a suggestion for development
>
>  -----Original Message-----
> From: Mark Nudelman [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, January 05, 2000 14:56
> To: [EMAIL PROTECTED]
> Subject: Re: StrPrintF
>
> Um, but this code doesn't do anything.  Since "text" is allocated as the
> same size as the input buffer (s), this doesn't provide any protection.
> It just does an unnecessary StrNCopy.  You want to call MemPtrNew with a
> LARGER size, a size that's large enough to handle any formatStr.
> Unfortunately, there is no such size, so the best you can do is estimate
> the largest size your app will need and use that.  It's unfortunate that
> Palm didn't provide a printf-like variant that calls a callback function
> to output each char into the buffer.  Then you could do a real
> StrNPrintF without an extra buffer.  Of course, you could write your own
> from scratch by duplicating all the logic in StrNPrintF.
> --Mark
>
>
> more - deleted
>
>

Reply via email to