Use of TCalendarDialog lazarus / 31-LCL ---------------------------------------------------------------------- nightrider · 2013-09-19 20:57 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 · 2013-09-19 22:14 Quote from: nightrider on September 19, 2013, 10:57:47 pmWhere 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 · 2013-09-19 22:33 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. ---------------------------------------------------------------------- nightrider · 2013-09-19 22:59 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 · 2013-09-20 03:32 :-)  I think I see, the parameters to IfThen were all evaluated at the same time, or at least not in the order you expected. ---------------------------------------------------------------------- nightrider · 2013-09-20 21:15 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 · 2013-09-20 22:19 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. ---------------------------------------------------------------------- Mike.Cornflake · 2013-09-21 00:09 Quote from: wp on September 21, 2013, 12:19:19 amIt 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. ---------------------------------------------------------------------- nightrider · 2013-09-21 20:07 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 · 2013-09-21 20:56 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'); ---------------------------------------------------------------------- nightrider · 2013-09-22 13:43 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 · 2013-09-22 16:29 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.