with sizeof formatStr you are getting just 4 couse it is a pointer, you cant
get sizeof(ptr) for a string, you get the size of a pointer (DWORD)
with, strlen(fromatStr) you get the length of the strings but with the %s %d
etc not replaced, it's not what you need.
you cannot do StrLen of args, va_start takes the args depending of what is
in %s and %d from the stack, so you get nothing with strlen. I am not sure
if you can check that, but a way I could think of is to alloc a temporary
buffer much bigger than yours, for example 256 or 512 bytes and perfrom the
strvprintf in the buffer, then you can calculate the StrLen(tmpBuffer) to
check the length of the output buffer and then compare it with size, if the
length is bigger then you can show an alert or return an error, if not, you
can just copy the string in tmpbuffer to your buffer and then free
everything. You also whould check men allocking for any error code because
if you are short of memory you may have an allocking error (not enough
memory) remember: PALM IS NOT LIKE PC :)
See ya!
----- Original Message -----
From: Charles Rezsonya <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, January 07, 2000 1:01 PM
Subject: Re: StrPrintF
> is there a way to have the strNPrintF example to get a length of the args
> added into the formated string before writing it? i ask this because when
i
> run the example in pose it complains that the buffer is to small and
writes
> to data structures or something (some error). or is it possible to have
it
> start writing to the buffer but stop at the specified length?
>
> heres what i have so far....
>
> /***********************************************************************/
> Boolean StrNPrintF(CharPtr s, UInt size, CharPtr formatStr, ...) {
> // Char text[size];
> Int i, j, k, l, m;
> Boolean failed;
> Char *text;
> va_list args;
> va_start(args, formatStr);
>
> i=sizeof(formatStr); ///
> j=sizeof(args); ///
> k=StrLen(formatStr);
> l=StrLen(args);
>
> text=MemPtrNew(size);
> StrVPrintF(text, formatStr, args);
> m=StrLen(text);
> va_end(args);
>
> StrNCopy(s, text, size);
>
> // if(i>size) {
> // FrmCustomAlert(TestAlert, "Too long for variable", (Char*)"test",
NULL);
> // failed=true;
> // }else{
> failed=false;
> // }
> MemPtrFree(text);
> return(failed);
> }
>
> pardon the extra redundant code, i've been trying a few differant things
to
> try to get what i need
>
> -----Original Message-----
> From: Chris Antos <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
> Date: Thursday, January 06, 2000 1:17 PM
> Subject: Re: StrPrintF
>
>
> >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
> >>
> >>
> >
> >
>
>
>
>
