GetNumberFormat

Mark Wilden

unread,

Apr 6, 1997, 4:00:00 AM4/6/97

to

Does anyone know of an easy way to get GetNumberFormat to not use decimal
places? It seems utterly ridiculous to me that the default number of
decimal places in a number would be considered a regional characteristic!

What I've resorted to is this, but I don't like it:

char buf[100];
GetLocaleInfo(LOCALE_USER_DEFAULT, LOCALE_IDIGITS, buf, sizeof buf);
int nDecimalDigits = atoi(buf);

sprintf(buf, "%d", value);
GetNumberFormat(LOCALE_USER_DEFAULT, 0, strSrc, 0, buf, sizeof buf);

// chop off decimal portion
cp[strlen(cp) - nDecimalDigits - 1] = 0;

David Lowndes

unread,

Apr 8, 1997, 3:00:00 AM4/8/97

to

Your method is more concise than the one I used Mark. I too was
suprised that there is no easy way of printing integer numbers without
decimal places. Here's what I'd used:

char szFileSize[ 15 ];

_itoa( 123456, szFileSize, 10 );

static NUMBERFMT nf;

/* Only do this once! It's rather long winded */
if ( nf.lpThousandSep == NULL )
{
char szBuffer[5];
static char szDecSep[5];
static char szThousandsSep[5];

GetLocaleInfo( LOCALE_USER_DEFAULT, LOCALE_SDECIMAL,
&szDecSep[0], sizeof( szDecSep ) );
GetLocaleInfo( LOCALE_USER_DEFAULT, LOCALE_STHOUSAND,
&szThousandsSep[0],
sizeof( szThousandsSep ) );

/* We want no fractions */
nf.NumDigits = 0;

/* But all the system defaults for the others */
GetLocaleInfo( LOCALE_USER_DEFAULT, LOCALE_ILZERO,
&szBuffer[0], sizeof( szBuffer ) );
nf.LeadingZero = atoi( szBuffer );
GetLocaleInfo( LOCALE_USER_DEFAULT, LOCALE_SGROUPING,
&szBuffer[0], sizeof( szBuffer ) );
nf.Grouping = atoi( szBuffer );
nf.lpDecimalSep = szDecSep;
nf.lpThousandSep = szThousandsSep;
GetLocaleInfo( LOCALE_USER_DEFAULT, LOCALE_INEGNUMBER,
&szBuffer[0], sizeof( szBuffer ) );
nf.NegativeOrder = atoi( szBuffer );
}

/* Convert the number string into the proper locale defn */
GetNumberFormat( LOCALE_USER_DEFAULT, 0, szFileSize,
&nf, szSize, sizeof( szSize ) );

Dave
----
Address is altered to discourage junk mail.
Remove ".---" for the real address.

Mark Wilden

unread,

Apr 8, 1997, 3:00:00 AM4/8/97

to

Thanks a lot for posting that, David. It was too tedious for me to bother
with, but hey, I can cut and paste as well as the next guy. :)

Your code is better because it handles the case of the negative sign going
at the end of the number.

David Lowndes

unread,

Apr 9, 1997, 3:00:00 AM4/9/97

to

Oh well, glad you found it useful Mark. Tedious to have to do it
though, I'd hoped there was a neater way.

Mark Wilden

unread,

Apr 9, 1997, 3:00:00 AM4/9/97

to

I'm beginning to _expect_ tedium from trying to be globally friendly with
Win32. For example, why on earth would functions called GetNumberFormat and
GetCurrencyFormat want _strings_ as input parameters?

David Lowndes <dav...@mvps.org.---> wrote in article

Mark Wilden

unread,

Apr 9, 1997, 3:00:00 AM4/9/97

to

David Lowndes <dav...@mvps.org.---> wrote in article

<334c22c1...@msnews.microsoft.com>...

> >I'm beginning to _expect_ tedium from trying to be globally friendly
with
> >Win32. For example, why on earth would functions called GetNumberFormat
and
> >GetCurrencyFormat want _strings_ as input parameters?
>

> Yes, that struck me as being too long winded to imagine anyone
> willingly designing it that way.

That's the point--there must have been _some_ reason for this design. Sure
be curious to know what it was, though.

> Still that's the way it is!

Quite right. I only bitch in hopes that someone will explain the behavior.
:)

David Lowndes

unread,

Apr 10, 1997, 3:00:00 AM4/10/97

to

>I'm beginning to _expect_ tedium from trying to be globally friendly with
>Win32. For example, why on earth would functions called GetNumberFormat and
>GetCurrencyFormat want _strings_ as input parameters?

Yes, that struck me as being too long winded to imagine anyone

willingly designing it that way. Still that's the way it is!

Cheers

Ben Goetter

unread,

Apr 11, 1997, 3:00:00 AM4/11/97

to

In article <01bc44c6$8f75b2c0$280228ce@default>, "Mark Wilden" <Ma...@mWilden.com> wrote:
>For example, why on earth would functions called GetNumberFormat and
>GetCurrencyFormat want _strings_ as input parameters?

To keep them from having to accept "float" or "double" parameters, with the
attending format problems (64-bit? 80-bit?) that would cause, I imagine.

Fundamentally, they're text-formatting APIs. There's no call to go linking FP
support into the API just to move some decimal points and commas around in a
string.

--
Ben Goetter, Angry Graycat Designs
http://www.angrygraycat.com/goetter/

Mark Wilden

unread,

Apr 11, 1997, 3:00:00 AM4/11/97

to

Ben Goetter <goe...@angrygraycat.com> wrote in article
<5ill62$td9$1...@brokaw.wa.com>...

> In article <01bc44c6$8f75b2c0$280228ce@default>, "Mark Wilden"
<Ma...@mWilden.com> wrote:
> >For example, why on earth would functions called GetNumberFormat and
> >GetCurrencyFormat want _strings_ as input parameters?
>
> To keep them from having to accept "float" or "double" parameters, with
the
> attending format problems (64-bit? 80-bit?) that would cause, I imagine.

Surely in this day and age where floating point support is builtin to the
CPU, double is not exactly an esoteric format?

> Fundamentally, they're text-formatting APIs. There's no call to go
linking FP
> support into the API just to move some decimal points and commas around
in a
> string.

Well, to use them, one is obviously going to have to link FP support in
somewhere. These functions aren't just "text formatting" functions--they're
functions to format text that has been formatted from numbers. At some
point, you have to deal with numbers--my question is why these functions
require a two-step process?