Hi,

Is there any specific reason why TDateEdit.Date is not published? That's kind of an important property for that component.

Is TDateEdit the equivalent to TDateTimePicker of Delphi's VCL?

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

You would have to ask Mattias and Aleksey:
http://svn.freepascal.org/cgi-bin/viewvc.cgi?view=rev&root=lazarus&revision=10189

Vincent

Googling for: Can somebody explain me the reasons behind the changes in revision 10189?
gives:
http:/msg12342.html

Vincent

En/na Vincent Snijders ha escrit:

As a side note, nulldate is actually set to a valid date (0 is 30/12/1899), not a common date in everyday use, but one could need it if, say, managing historical records.
Maybe a more sensible nulldate would be JulianDate or -DateDelta?

Bye

OK, thanks Vincent.

And another reason DateTime and Currency should not be simply types. Lots of hacks are required to get null support, fix rounding issues etc... But that's a whole other topic. ;-)

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

Luca Olivetti wrote

As a side note, nulldate is actually set to a valid date (0 is 30/12/1899), not a common date in everyday use, but one could need it

Hence my comment about TDateTime and Currency that are not supposed to have been simple types. :-) They are so flawed in design it's just scary. Try and do multi-currency calculations with a Currency type. Try and calculate the difference between dates or like you pointed out, setting it to a true null value. Thank goodness for Value Object design pattern. ;-)

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

Graeme Geldenhuys wrote

On Thu, Apr 23, 2009 at 4:51 PM, Luca Olivetti wrote: scary. ?Try and do multi-currency calculations with a Currency type.

Just out of curiosity, where's the problem?

Regards,

Gerard.

Gerard N/A wrote

> scary. ?Try and do multi-currency calculations with a Currency type. Just out of ?curiosity, where's the problem?

Example #1
------------------
var
  cUSD: Currency;
  cGBP: Currency;
  cEuro: Currency;
  cSum: Currency;
begin
  cUSD := 1.00;
  cGBP := 1.00;
  cEuro := cUSD + cGBP;
  cSum := cUSD + cGBP;

Problem #1:
cEuro is only valid if exchange rate is 1:1. Which pretty much guaranteed not to be the case in this day and age.

Problem #2:
What currency is cSum in? Dollars or Pounds or something else?

...there are a few more issues like rounding, allocation of lost decimals in case of rounding errors, etc... :-) A simple type simply cannot handle such complex cases correctly.

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

I don't get it. Why would you add USD and GBP and assign the result to a variable wich is supposed to hold Euros?

...there are a few more issues like rounding, allocation of lost decimals in case of rounding errors, etc... ?:-) ?A simple type simply cannot handle such complex cases correctly.

Ok, maybe the name "currency" can be confusing. Curency is a fixed point real type with 4 decimal places.
Anyway, handling conversions between currencies requires more than even a simple class.
You would need to know at least what is the exchange rate for a given conversion.

Regards,

Gerard.

Gerard N/A wrote

I don't get it. Why would you add USD and GBP and assign the result to a variable wich is supposed to hold Euros?

Think in terms of an accounting application that supports billing in multiple currencies. Or clients that pay there bills in there own currency, while the default currency is something else.

Ok, maybe the name "currency" can be confusing. Curency is a fixed point real type with 4 decimal places. Anyway, handling conversions between currencies requires more than even a simple class.

Exactly my point. :-)

You would need to know at least what is the exchange rate for a given conversion.

And the currency type and the rounding method use (maybe even per currency) and the preferred decimal numbers used (again maybe per currency) etc...

Something that seemed so simple in the beginning can become quite a complex task. ;-)

Now similar issue can be applied to TDateTime and String types. All I can say is thank goodness for Value Type Frameworks which get around these problems. Business objects are defined using class types instead of simple types. Anyway, this thread is getting a bit off-topic now.

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

Indeed. My dream would be to have some sort of extendable RTTI or at least nulalble types.
A good VTF is a solution, in the meantime. ;-)

Regards,

Gerard.

Gerard N/A wrote

Indeed. My dream would be to have some sort of extendable RTTI or at least nulalble types.

MSEgui uses -Inf as null-TDatetime and null-double values which solves some of the problems.

Martin

Monetary calculations often are prescribed precisely, e.g. for taxes. These prescriptions as well as the preferred scaling are country specific. We just had a discussion about currencies where the base unit equals e.g. 1E-6 USD, where 64 bit and 4 decimal places are no more applicable, even for calculations in one currency.

Something that seemed so simple in the beginning can become quite a complex task. ;-) Now similar issue can be applied to TDateTime and String types.

Unlike other measure types (including date, temparature, length...), currencies have variable conversion rules or factors. In former days (some) currencies were based on gold or silver (Pound Sterling, Silverdollar, Goldmark...), usable as a common base for exchange calculations, but nowadays IMO all currencies are floating. Any fixed conversion methods will result in kind of weather forecast ;-)

DoDi

The Currency type is just a float with 4 decimal places and some special rounding behaviour that I cannot remember. Currency conversions and all the rest is up to you as a programmer and your application.

I think that TDateEdit.Date should be published. This is the behaviour of the JEDI TJvDateEdit and the Delphi date picker. If this exposes a bug then that is what needs to be fixed.

</div>