Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / lazarus / 2008-09

FloatToStrIntl

8 messages · 2 people · –

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Pavel Řezníček

Hello all,

On Lazarus v0.9.25 r16541 i386-win32-win32/win64, I have the following problem.

I access an SQLite3 database. There I have a column defined as numeric(3), it means, 3 whole number digits and no decimal places. The table has to be synchronised with PostgreSQL using the same table name and column names. Therefore the column definition is simply taken from the PostgreSQL definition.

The data is maybe stored correctly in the database but when I call the AsString property on that field, I don't get e. g. '14' as expected but '0,0014'.

I tried to track it down and I got somewhere into the FloatToStrIntl function which actually returns that worngly formatted number. The input parameter to that function (the number) seems to still have the correct value (14). So I suppose the problem's raised by that conversion function; still not sure, maybe the function isn't called well.

Here you have the critical part of the call stack:

#0 :1148
#1 FLOATTOSTRF(14, FFGENERAL, -1, 0, {CURRENCYFORMAT = 3, NEGCURRFORMAT = 8, THOUSANDSEPARATOR = 160 #160, DECIMALSEPARATOR = 44 ',', CURRENCYDECIMALS = 2, DATESEPARATOR = 46 '.', TIMESEPARATOR = 58 ':', LISTSEPARATOR = 44 ',', CURRENCYSTRING = 0x656a0 'K'#232, SHORTDATEFORMAT = 0x6d870 'd.M.yyyy', LONGDATEFORMAT = 0x6d890 'd. MMMM yyyy', TIMEAMSTRING = 0x6d8b0 'dop.', TIMEPMSTRING = 0x6d8d0 'odp.', SHORTTIMEFORMAT = 0x6d8f0 'h:nn', LONGTIMEFORMAT = 0x6d910 'h:nn:ss', SHORTMONTHNAMES = {0x65570 'I', 0x65580 'II', 0x65590 'III', 0x655a0 'IV', 0x655b0 'V', 0x655c0 'VI', 0x655d0 'VII', 0x6d6d0 'VIII', 0x655e0 'IX', 0x655f0 'X', 0x65600 'XI', 0x65610 'XII'}, LONGMONTHNAMES = {0x6d5f0 'leden', 0x6d610 #250'nor', 0x6d630 'b'#248'ezen', 0x6d650 'duben', 0x6d670 'kv'#236'ten', 0x6d690 #232'erven', 0x6d6b0 #232'ervenec', 0x6d6f0 'srpen', 0x6d710 'z'#225#248#237, 0x6d730 #248#237'jen', 0x6d750 'listopad', 0x6d770 'prosinec'}, SHORTDAYNAMES = {0x65620 'ne', 0x65630 'po', 0x65640 #250't', 0x65650 'st', 0x65660 #232't', 0x65670 'p'#225, 0x65680 'so'}, LONGDAYNAMES = {0x6d790 'ned'#236'le', 0x6d7b0 'pond'#236'l'#237, 0x6d7d0 #250'ter'#253, 0x6d7f0 'st'#248'eda', 0x6d810 #232'tvrtek', 0x6d830 'p'#225'tek', 0x6d850 'sobota'}, TWODIGITYEARCENTURYWINDOW = 50}) at sysstr.inc:1519 #2 FLOATTOSTRF(14, FFGENERAL, -1, 0) at sysstr.inc:1526 #3 CURRTOSTR(14) at sysstr.inc:1638
#4 :2218

Any help would be gladly appreciated :-)

Pavel ?ezn??ek

Reply by email

Michael Van Canneyt
to Pavel Řezníček
Pavel ?ezn??ek wrote 14 lines
Hello all, On Lazarus v0.9.25 r16541 i386-win32-win32/win64, I have the following problem. I access an SQLite3 database. There I have a column defined as numeric(3), it means, 3 whole number digits and no decimal places. The table has to be synchronised with PostgreSQL using the same table name and column names. Therefore the column definition is simply taken from the PostgreSQL definition. The data is maybe stored correctly in the database but when I call the AsString property on that field, I don't get e. g. '14' as expected but '0,0014'.

And this is correct.

The string is formatted according to the default float format. The underlying data format is not relevant. If you want this, set the DisplayFormat property to something FormatFloat understands. (I suppose '000')

Michael.

Reply by email

Pavel Řezníček
to Michael Van Canneyt

Michael Van Canneyt napsal(a):

Show quoted text 27 lines
On Sat, 13 Sep 2008, Pavel ?ezn??ek wrote: > Hello all, > > On Lazarus v0.9.25 r16541 i386-win32-win32/win64, I have the following > problem. > > I access an SQLite3 database. There I have a column defined as > numeric(3), it means, 3 whole number digits and no decimal places. The > table has to be synchronised with PostgreSQL using the same table name > and column names. Therefore the column definition is simply taken from > the PostgreSQL definition. > > The data is maybe stored correctly in the database but when I call the > AsString property on that field, I don't get e. g. '14' as expected but > '0,0014'. > And this is correct. The string is formatted according to the default float format. The underlying data format is not relevant. If you want this, set the DisplayFormat property to something FormatFloat understands. (I suppose '000') Michael.

OK, that's what I wanted to know and thank you for your help, Micha?l.

Still, excuse me for my newbie-fashioned question:

What does that '0,0014' mean? Does it mean 0.0014 in Pascal notation? If yes, why?
I suppose it's divided by 10 thousands. Why? Are you saying that the default float format divides numbers by 10 000? Strange to me ... though respectable.

Another point: Shouldn't the AsString property try to respect the underlying format? I know that SQLite is pretty "guessing" the type and format but still think that the way the field is defined should be of some revelance... Could we call this a feature request? :-)

Pavel

Reply by email

Pavel Řezníček
to Michael Van Canneyt: And this is correct. The string is formatted according to the default float format. The…

Michael Van Canneyt napsal(a):

Show quoted text 27 lines
On Sat, 13 Sep 2008, Pavel ?ezn??ek wrote: > Hello all, > > On Lazarus v0.9.25 r16541 i386-win32-win32/win64, I have the following > problem. > > I access an SQLite3 database. There I have a column defined as > numeric(3), it means, 3 whole number digits and no decimal places. The > table has to be synchronised with PostgreSQL using the same table name > and column names. Therefore the column definition is simply taken from > the PostgreSQL definition. > > The data is maybe stored correctly in the database but when I call the > AsString property on that field, I don't get e. g. '14' as expected but > '0,0014'. > And this is correct. The string is formatted according to the default float format. The underlying data format is not relevant. If you want this, set the DisplayFormat property to something FormatFloat understands. (I suppose '000') Michael.

Another comment:

Display Format has no effect here because the field is considered to be a TBCDField and there and DisplayFormat isn't used. Or am I wrong?

CurrToStr just calls FloatToStrF with some default parameters. No chance to use my own format from the point of view of the "user programmer" - until I go around the AsString property.

- fields.inc, line 2212:

function TBCDField.GetAsString: string;
var c : system.currency;
begin
  If GetData(@C) then
    Result:=CurrToStr(C)
  else
    Result:='';
end;

Pavel

Reply by email

Michael Van Canneyt
to Pavel Řezníček
Pavel ?ezn??ek wrote 49 lines
Michael Van Canneyt napsal(a): > On Sat, 13 Sep 2008, Pavel ?ezn??ek wrote: > > >> Hello all, >> >> On Lazarus v0.9.25 r16541 i386-win32-win32/win64, I have the following >> problem. >> >> I access an SQLite3 database. There I have a column defined as >> numeric(3), it means, 3 whole number digits and no decimal places. The >> table has to be synchronised with PostgreSQL using the same table name >> and column names. Therefore the column definition is simply taken from >> the PostgreSQL definition. >> >> The data is maybe stored correctly in the database but when I call the >> AsString property on that field, I don't get e. g. '14' as expected but >> '0,0014'. >> > > And this is correct. > > The string is formatted according to the default float format. > The underlying data format is not relevant. If you want this, > set the DisplayFormat property to something FormatFloat understands. > (I suppose '000') > > Michael. Another comment: Display Format has no effect here because the field is considered to be a TBCDField and there and DisplayFormat isn't used. Or am I wrong? CurrToStr just calls FloatToStrF with some default parameters. No chance to use my own format from the point of view of the "user programmer" - until I go around the AsString property. - fields.inc, line 2212: function TBCDField.GetAsString: string; var c : system.currency; begin If GetData(@C) then Result:=CurrToStr(C) else Result:=''; end;

This is a bug and should be corrected.

Michael.

Reply by email

Pavel Řezníček
to Michael Van Canneyt

Michael Van Canneyt napsal(a):

Show quoted text 60 lines
On Sat, 13 Sep 2008, Pavel ?ezn??ek wrote: > Michael Van Canneyt napsal(a): > >> On Sat, 13 Sep 2008, Pavel ?ezn??ek wrote: >> >> >> >>> Hello all, >>> >>> On Lazarus v0.9.25 r16541 i386-win32-win32/win64, I have the following >>> problem. >>> >>> I access an SQLite3 database. There I have a column defined as >>> numeric(3), it means, 3 whole number digits and no decimal places. The >>> table has to be synchronised with PostgreSQL using the same table name >>> and column names. Therefore the column definition is simply taken from >>> the PostgreSQL definition. >>> >>> The data is maybe stored correctly in the database but when I call the >>> AsString property on that field, I don't get e. g. '14' as expected but >>> '0,0014'. >>> >>> >> And this is correct. >> >> The string is formatted according to the default float format. >> The underlying data format is not relevant. If you want this, >> set the DisplayFormat property to something FormatFloat understands. >> (I suppose '000') >> >> Michael. >> > Another comment: > > DisplayFormat has no effect here because the field is considered to be > a TBCDField and there DisplayFormat isn't used. Or am I wrong? > > CurrToStr just calls FloatToStrF with some default parameters. No chance > to use my own format from the point of view of the "user programmer" - > until I go around the AsString property. > > - fields.inc, line 2212: > > function TBCDField.GetAsString: string; > > var c : system.currency; > > begin > If GetData(@C) then > Result:=CurrToStr(C) > else > Result:=''; > end; > This is a bug and should be corrected. Michael.

OK, I'm going to file a bugreport.

Pavel

Reply by email

Pavel Řezníček
to Michael Van Canneyt: This is a bug and should be corrected. Michael.

Michael Van Canneyt napsal(a):

Show quoted text 60 lines
On Sat, 13 Sep 2008, Pavel ?ezn??ek wrote: > Michael Van Canneyt napsal(a): > >> On Sat, 13 Sep 2008, Pavel ?ezn??ek wrote: >> >> >> >>> Hello all, >>> >>> On Lazarus v0.9.25 r16541 i386-win32-win32/win64, I have the following >>> problem. >>> >>> I access an SQLite3 database. There I have a column defined as >>> numeric(3), it means, 3 whole number digits and no decimal places. The >>> table has to be synchronised with PostgreSQL using the same table name >>> and column names. Therefore the column definition is simply taken from >>> the PostgreSQL definition. >>> >>> The data is maybe stored correctly in the database but when I call the >>> AsString property on that field, I don't get e. g. '14' as expected but >>> '0,0014'. >>> >>> >> And this is correct. >> >> The string is formatted according to the default float format. >> The underlying data format is not relevant. If you want this, >> set the DisplayFormat property to something FormatFloat understands. >> (I suppose '000') >> >> Michael. >> > Another comment: > > Display Format has no effect here because the field is considered to be > a TBCDField and there and DisplayFormat isn't used. Or am I wrong? > > CurrToStr just calls FloatToStrF with some default parameters. No chance > to use my own format from the point of view of the "user programmer" - > until I go around the AsString property. > > - fields.inc, line 2212: > > function TBCDField.GetAsString: string; > > var c : system.currency; > > begin > If GetData(@C) then > Result:=CurrToStr(C) > else > Result:=''; > end; > This is a bug and should be corrected. Michael.

By the way, where is the (main) problem? Please choose:

1) numeric(3) in the SQLite3 DB being interpreted as BCD/Currency (Is that correct? Shouldn't it be read just as a float - Double or Extended? I don't know?)
2) CurrToStr used, not allowing the DisplayFormat property to be applied
3) bad formatting by FloatToStrIntl (14 -> '0,0014')

Pavel

Reply by email

Michael Van Canneyt
to Pavel Řezníček
Pavel ?ezn??ek wrote 68 lines
Michael Van Canneyt napsal(a): > On Sat, 13 Sep 2008, Pavel ?ezn??ek wrote: > > >> Michael Van Canneyt napsal(a): >> >>> On Sat, 13 Sep 2008, Pavel ?ezn??ek wrote: >>> >>> >>> >>>> Hello all, >>>> >>>> On Lazarus v0.9.25 r16541 i386-win32-win32/win64, I have the following >>>> problem. >>>> >>>> I access an SQLite3 database. There I have a column defined as >>>> numeric(3), it means, 3 whole number digits and no decimal places. The >>>> table has to be synchronised with PostgreSQL using the same table name >>>> and column names. Therefore the column definition is simply taken from >>>> the PostgreSQL definition. >>>> >>>> The data is maybe stored correctly in the database but when I call the >>>> AsString property on that field, I don't get e. g. '14' as expected but >>>> '0,0014'. >>>> >>>> >>> And this is correct. >>> >>> The string is formatted according to the default float format. >>> The underlying data format is not relevant. If you want this, >>> set the DisplayFormat property to something FormatFloat understands. >>> (I suppose '000') >>> >>> Michael. >>> >> Another comment: >> >> Display Format has no effect here because the field is considered to be >> a TBCDField and there and DisplayFormat isn't used. Or am I wrong? >> >> CurrToStr just calls FloatToStrF with some default parameters. No chance >> to use my own format from the point of view of the "user programmer" - >> until I go around the AsString property. >> >> - fields.inc, line 2212: >> >> function TBCDField.GetAsString: string; >> >> var c : system.currency; >> >> begin >> If GetData(@C) then >> Result:=CurrToStr(C) >> else >> Result:=''; >> end; >> > > This is a bug and should be corrected. > > Michael. By the way, where is the (main) problem? Please choose: 1) numeric(3) in the SQLite3 DB being interpreted as BCD/Currency (Is that correct? Shouldn't it be read just as a float - Double or Extended? I don't know?) 2) CurrToStr used, not allowing the DisplayFormat property to be applied 3) bad formatting by FloatToStrIntl (14 -> '0,0014')

2 is the problem.

Michael.

Reply by email