Recent

Author Topic: Use of TCalendarDialog  (Read 26787 times)

nightrider

  • Full Member
  • ***
  • Posts: 139
Use of TCalendarDialog
« on: September 19, 2013, 10:57:47 pm »
I need to give the user of a program the facility of select a date. I do:

  DialogDate.Date:=now;
  edit1.Text := IfThen(DialogDate.Execute,DateToStr(dialogDate.date),'selecione uma data');

It doesn't matter what day I select in the visual component i ever receive the "now" date in the edit1.Text.

Where is the mistake?

Greetings from Sao Paulo - Brazil

Ricardo

howardpc

  • Hero Member
  • *****
  • Posts: 3178
Re: Use of TCalendarDialog
« Reply #1 on: September 20, 2013, 12:14:55 am »
Where is the mistake?

Seems to be a bug in TCalendarDialog. Can you report it?
(I presume you have written your own IfThen() function, since the one in the math unit returns a double value).

wp

  • Hero Member
  • *****
  • Posts: 6331
Re: Use of TCalendarDialog
« Reply #2 on: September 20, 2013, 12:33:55 am »
It's working with me (Win 32, Laz 1.1 trunk, fpc 2.6.2).

I usually prefer less compact code for better readability. Is this following code working?

Code: [Select]
DialogDate.Date := now;
if DialogDate.Execute then
  Edit1.Text := DialogDate.Date
else
  Edit1.Text := 'selecione uma data';

There are several overloads for the IfThen function: in Sysutils for strings, in Math for numbers, in TAChartUtils for objects - and maybe some more.
Lazarus trunk / fpc 3.0.4 / all 32-bit on Win-10

nightrider

  • Full Member
  • ***
  • Posts: 139
Re: Use of TCalendarDialog
« Reply #3 on: September 20, 2013, 12:59:59 am »
When I wrote:

  DialogDate.Date:=now;
  edit1.Text := IfThen(DialogDate.Execute,DateToStr(dialogDate.date),'selecione uma data');
  edit1.Text := DateToStr(dialogDate.date);

The correct date begin to appear in the editbox. I don't know if it is a bug. I suppose it is.

The IfThen I use to use is that one find in the StrUtils unit.

Thanks for everybody

Mike.Cornflake

  • Hero Member
  • *****
  • Posts: 1249
Re: Use of TCalendarDialog
« Reply #4 on: September 20, 2013, 05:32:33 am »
:-)  I think I see, the parameters to IfThen were all evaluated at the same time, or at least not in the order you expected.
Lazarus Trunk/FPC Trunk on Windows [7, 10]
  Have you tried searching this forum or the wiki?:   http://wiki.lazarus.freepascal.org/Alternative_Main_Page
  BOOKS! (Free and otherwise): http://wiki.lazarus.freepascal.org/Pascal_and_Lazarus_Books_and_Magazines

nightrider

  • Full Member
  • ***
  • Posts: 139
Re: Use of TCalendarDialog
« Reply #5 on: September 20, 2013, 11:15:13 pm »
I think that or a command is executed or not. In this case the sequence is so clear. I'll abandon thes construction and solve the trouble in other way. Commands with different behaviors in differente situations are not reliable.

Thank you for you attention


wp

  • Hero Member
  • *****
  • Posts: 6331
Re: Use of TCalendarDialog
« Reply #6 on: September 21, 2013, 12:19:19 am »
Just to make things clear: http://stackoverflow.com/questions/11010456/in-delphi-are-parameters-evaluated-in-order-when-passed-into-a-method discusses the order in which parameters are evaluated that are passed to a procedure or function. It looks that Win-32 uses left-to-right order -- which explains why I don't see the issue with Win32. But Win64 uses right-to-left order - this means that the IfThen function evaluates the second parameter (DateToStr(...)) is evaluated before the DateDialog is executed and, therefore, the result of Execute is ignored.
Lazarus trunk / fpc 3.0.4 / all 32-bit on Win-10

Mike.Cornflake

  • Hero Member
  • *****
  • Posts: 1249
Re: Use of TCalendarDialog
« Reply #7 on: September 21, 2013, 02:09:40 am »
It looks that Win-32 uses left-to-right order -- which explains why I don't see the issue with Win32. But Win64 uses right-to-left order

I've always wondered.  Many thanks for the information.
Lazarus Trunk/FPC Trunk on Windows [7, 10]
  Have you tried searching this forum or the wiki?:   http://wiki.lazarus.freepascal.org/Alternative_Main_Page
  BOOKS! (Free and otherwise): http://wiki.lazarus.freepascal.org/Pascal_and_Lazarus_Books_and_Magazines

nightrider

  • Full Member
  • ***
  • Posts: 139
Re: Use of TCalendarDialog
« Reply #8 on: September 21, 2013, 10:07:57 pm »
What?!

The order of evaluation of expressions changes from Win32 to Win64 version? Although I'm running Win32 version I can't believe.

If I compile a Windows 32 source in the Win 64 of Lazarus the logic of execution changes????

Again: I can't believe...

cheers

howardpc

  • Hero Member
  • *****
  • Posts: 3178
Re: Use of TCalendarDialog
« Reply #9 on: September 21, 2013, 10:56:19 pm »
In addition to variation in the order parameters are processed, there may also be variation arising from compiler optimisations.
With the code:
Code: [Select]
  DialogDate.Date:=now;
  edit1.Text := IfThen(DialogDate.Execute,DateToStr(dialogDate.date),'selecione uma data');
the compiler sees the equivalence of now() and DialogDate.Date from the first statement, and may well optimise away DialogDate from the second parameter of the IfThen() call which is compiled into assembler instructions as:
Code: [Select]
  edit1.Text := IfThen(DialogDate.Execute,DateToStr(Now),'selecione uma data');
« Last Edit: September 22, 2013, 01:10:27 pm by howardpc »

nightrider

  • Full Member
  • ***
  • Posts: 139
Re: Use of TCalendarDialog
« Reply #10 on: September 22, 2013, 03:43:00 pm »
Again I can't believe. Is it possible that optimization techniques change the logic wrote by the programmer?

If things are this way, programmers must to know about compilation/optimization techniques. They need to became compiler specialists. I prefer to think I'm a compiler user...

I give up. If a construction doesn't function as expect, I change the construction.

Although I insist: A compiler must not change the program logic.




howardpc

  • Hero Member
  • *****
  • Posts: 3178
Re: Use of TCalendarDialog
« Reply #11 on: September 22, 2013, 06:29:25 pm »
To use a tool effectively you need to understand how it works, potential quirks, pitfalls etc. as well as the basic more straightforward operations.
A tool as complex as the FPC compiler is not going to be mastered overnight. The official documentation (FPLanguageRef, FPProgrammer's Guide, FPUser's Guide) runs to over 520 pages already.
As used in Lazarus to program GUI apps, various more complex program features are called into play, including the unpredictability of the event-driven paradigm in which user-induced variation at runtime is a designed-in feature, not a bug.
As wp indicated, a straightforward if ... then ... else construct will ensure that the DialogDate.Date property is set before the user sees the dialog, that the dialog is subsequently called (DialogDate.Execute) by the user, and that the resulting value of DialogDate.Date is only read after that, at runtime, after the user has chosen a date.
Since the OP introduced a different program construct than a simple if/then/else (a function with three parameters) he is then at the mercy of how that function is implemented in detail by the compiler. "The devil is in the detail".
It is not that the compiler has changed any logic. It is that we as programmers often fail to understand the detailed logic of complex constructs that we write. Hopefully we learn from finding that a particular construct (perfectly logical to the compiler) does not have the effect we intended. Occasionally we uncover a compiler bug. But usually the shortcoming in faulty code results from our own inability to see that there is a difference between the algorithm we expected our code would implement and what we actually told the compiler to do.