Subject | DOUBLE PRECISON fields with CURRENCY attribute now works... |
---|---|
Author | jocelyndionne@uraeus.qc.ca |
Post date | 2001-02-10T21:42:41Z |
Hello Jason.
Last week, I found what was wrong in the code about a little bug in
the formatting of currency values. After the modification,
everything was OK for the fields defined as NUMERIC and DECIMAL. You
asked me to email you the modified file. I did it and I also said
that I will look at the code to fix another bug related to the
currency format, but this time, with DOUBLE PRECISION fields.
For DOUBLE PRECISION and FLOAT fields as well, I have found that the
IsCurrency property is not set to True, even if I specify 'CURRENCY'
in the column attributes. So, we are not able to get these field
types formatted as currency. I looked in the code this weekend and
found why.
First of all, if I define a field of type NUMERIC or DECIMAL in a
table and specify it as a CURRENCY field in the column attributes,
the TIB_Column object will be created from the class
TIB_ColumnNumeric, not with the class TIB_ColumnCurr as I first
thought. The IsCurrency property is set to true in the constructor
of the class TIB_ColumnNumeric, so the currency formatting is done in
the GetDisplayText and everything is OK.
But if I define a field of type DOUBLE PRECISION in a table and
specify it as a CURRENCY field in the column attributes, the
TIB_Column object will be created from the class TIB_ColumnCurr. The
problem here is that the FIsCurrency flag is never set to true or
false because the column attributes are never verified like it is in
the constructor of the class TIB_ColumnNumeric. I added a
constructor for the class TIB_ColumnCurr where I copied and pasted
what was appropriate from the constructor of the class
TIB_ColumnNumeric. Now, the formatting is OK for every fields
defined as 'DOUBLE PRECISION' in a table and 'CURRENCY' in IBO.
If I define a field of type FLOAT in a table and specify it as a
CURRENCY field in the column attributes, nothing is done in the code
to verify if it's a currency field and the TIB_Column object will be
created from the class TIB_ColumnFloat. So, we are not able to
define a FLOAT type and use it as a currency field. I don't really
care about this because I never use FLOAT for currency fields but
it's interesting to know this.
That being said, I have one question about the class TIB_ColumnCurr.
Why the value in a TIB_ColumnCurr is multiplied by 10000 when 'set'
and divided by 10000 when 'get'. 2500 entered in a IBO control
becomes 250000000 in the table. The problem here is when we have a
table that already exists with DOUBLE PRECISION fields before using
IBO. Every numbers entered in the table are divided by 10000 before
appearing on the screen (Ouch!!!). 2500 becomes .25 . Unless
someone finds a very good reason to do this, I think it's absolutely
useless. And imagine if we use another development tool, every
numbers need to be divided by 10000 in the other application before
to use them. So, maybe it would be a good thing to delete this
portion of code.
So now, currency is OK for the DOUBLE PRECISION fields, except for
the divide/multiply by 10000 operation that I need to understand. I
know that when currency type deals with other real types, Delphi does
the divide/multiply by 10000 operation automatically. I'm not sure
if this was put in the code for that reason...
If you need more information or if you want the files that were
modified for this fix, tell me and I will send them by email.
Best regards,
Jocelyn Dionne.
Last week, I found what was wrong in the code about a little bug in
the formatting of currency values. After the modification,
everything was OK for the fields defined as NUMERIC and DECIMAL. You
asked me to email you the modified file. I did it and I also said
that I will look at the code to fix another bug related to the
currency format, but this time, with DOUBLE PRECISION fields.
For DOUBLE PRECISION and FLOAT fields as well, I have found that the
IsCurrency property is not set to True, even if I specify 'CURRENCY'
in the column attributes. So, we are not able to get these field
types formatted as currency. I looked in the code this weekend and
found why.
First of all, if I define a field of type NUMERIC or DECIMAL in a
table and specify it as a CURRENCY field in the column attributes,
the TIB_Column object will be created from the class
TIB_ColumnNumeric, not with the class TIB_ColumnCurr as I first
thought. The IsCurrency property is set to true in the constructor
of the class TIB_ColumnNumeric, so the currency formatting is done in
the GetDisplayText and everything is OK.
But if I define a field of type DOUBLE PRECISION in a table and
specify it as a CURRENCY field in the column attributes, the
TIB_Column object will be created from the class TIB_ColumnCurr. The
problem here is that the FIsCurrency flag is never set to true or
false because the column attributes are never verified like it is in
the constructor of the class TIB_ColumnNumeric. I added a
constructor for the class TIB_ColumnCurr where I copied and pasted
what was appropriate from the constructor of the class
TIB_ColumnNumeric. Now, the formatting is OK for every fields
defined as 'DOUBLE PRECISION' in a table and 'CURRENCY' in IBO.
If I define a field of type FLOAT in a table and specify it as a
CURRENCY field in the column attributes, nothing is done in the code
to verify if it's a currency field and the TIB_Column object will be
created from the class TIB_ColumnFloat. So, we are not able to
define a FLOAT type and use it as a currency field. I don't really
care about this because I never use FLOAT for currency fields but
it's interesting to know this.
That being said, I have one question about the class TIB_ColumnCurr.
Why the value in a TIB_ColumnCurr is multiplied by 10000 when 'set'
and divided by 10000 when 'get'. 2500 entered in a IBO control
becomes 250000000 in the table. The problem here is when we have a
table that already exists with DOUBLE PRECISION fields before using
IBO. Every numbers entered in the table are divided by 10000 before
appearing on the screen (Ouch!!!). 2500 becomes .25 . Unless
someone finds a very good reason to do this, I think it's absolutely
useless. And imagine if we use another development tool, every
numbers need to be divided by 10000 in the other application before
to use them. So, maybe it would be a good thing to delete this
portion of code.
So now, currency is OK for the DOUBLE PRECISION fields, except for
the divide/multiply by 10000 operation that I need to understand. I
know that when currency type deals with other real types, Delphi does
the divide/multiply by 10000 operation automatically. I'm not sure
if this was put in the code for that reason...
If you need more information or if you want the files that were
modified for this fix, tell me and I will send them by email.
Best regards,
Jocelyn Dionne.