At 4:36 PM -0800 2000/01/31, Chris Antos wrote:
> > Actually this sounds like an error in both versions of the documentation
> > quoted above. I don't think the function itself has really changed much.
> > The header <DateTime.h> contains these values which are probably intended
> > for DateToDOWDMFormat:
> >
> > #define dowDateStringLength 19
> > #define dowLongDateStrLength 25
>
>you must be looking at the 3.5 headers or something, because the 3.0 headers
>do NOT have either of those #defines. which illustrates my point.
Heh heh... and none of them have this declaration from DateTime.c:
// Max length of any date template string (before expansion), with the null.
#define maxDateTemplateLen 32
which is the maximum size of the conversion buffer, and thus the maximum size of the
resulting string, including the zero byte C-string terminator.
>the API seems to have an inherent backward compatibility flaw. i don't
>really care whether the code has changed or not; the incorrect headers and
>docs have generated a situation where it is not realistically possible for a
>developer to have coded a call to this API that will actually work on all OS
>versions.
I must be missing something... you can't just pass a 32-byte buffer for all OS
versions?
Or do you mean a forward compatibility problem... i.e. an application written for 2.0
using timeStringLength would overflow the buffer under 3.5 if the conversion required
dowLongDateStrLength bytes? Yes, that's a problem -- the price of progress and
correcting the documentation.
Keep in mind a LOT of things changed from OS 2.0 to OS 3.0 and again from 3.0 to 3.5.
Generally speaking as the OS evolves, it will become increasingly difficult to
maintain a single version of an application which functions correctly under all OS
versions. do History() while (1); // history always repeats itself
Regards,
Jim Schram
3Com/Palm Computing
Partner Engineering
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palm.com/devzone/mailinglists.html
