TDatePicker control

[Zoran]

Please, testing on other platforms is needed.

So far it's tested on Windows and Linux with gtk2.

Can someone try it on Mac?

[zeljko]

I'll do tests with qt (linux, win32, mac) tonight and send you feedback, and if I have some spare time I'll recompile qtmac laz to carbon laz and test on carbon also.

[Zoran]

I'll do tests with qt (linux, win32, mac) tonight and send you feedback, and if I have some spare time I'll recompile qtmac laz to carbon laz and test on carbon also.

Thank you, Željko, looking forward to your results.

[zeljko]

Here are some preliminary results (qt linux,win32 & mac).
Painting is ok, control looks ok but I have some observations:
1.Please change  IFDEF WINDOWS to IFDEF LCLWin32 since qt & gtk2 works on windows platform too.
2.Handling calendar click (closeCalendarForm) isn't ok (calendarMouseUp()).
 Under qt ws, dateChanged()->LCL is passed after click (QEventMouseRelease), so if you close calendar from MouseUp event, qt calendar doesn't have enough time to change date and send signal which will be processed by LCL, so with one click, date in datepicker edit controls stays unchanged.
My proposal would be to handle Calendar.OnChange(SO YOU CAN CLOSE FORM HERE), with saved variable for hitTest() inside MouseUp.Only way I can get date change via TCalendar with qt ws is to navigate with keys and then press space (qt fires dateChange() -> LCL) and then click (closes calendar form and got right date).

3.Also direct date editing should be more flexibile, like in TMaskEdit. eg I cannot write 01 for date (leading zero), it's automated, but confuses user.

that's it

zeljko

[LuizAmérico]

I propose to Zoran put the code in a svn repository like Lazarus-ccr so we can follow the development closer and allow to make patches easier like the proposed changes by zeljko.

Anyway, good work Zoran. It's an useful component.

[zeljko]

I propose to Zoran put the code in a svn repository like Lazarus-ccr so we can follow the development closer and allow to make patches easier like the proposed changes by zeljko.

Anyway, good work Zoran. It's an useful component.

I already mentioned that I'd like to see this component in lazarus components (palette) , so better to have this basic component in lazarus/components than in lazarus-ccr. It's automatically closer to others laz developers since I'm not sure if everyone is taking an eye blink over lazarus-ccr every day (in my case it's monthly).
So my proposal would be lazarus/components instead of lazarus-ccr , just because it's very important component, and deserves default place on lazarus components tab

zeljko

[Zoran]

1.Please change  IFDEF WINDOWS to IFDEF LCLWin32 since qt & gtk2 works on windows platform too.

There are three procedures where I had to put IFDEFs. I'm not sure that each should be changed to IFDEF LCLWin32 (maybe it should be IFDEF LCLGtk2 or something else). To do some testing I installed gtk2 on Windows to see the behavior in this combination. Uh... wasn't quite pleasent experience... seeing this face of our Lazarus. 

The first IFDEF is in SetShowCheckBox procedure. It is there to avoid buggy behaviour of TCheckBox I experienced when testing on Linux. To see what I mean, I'm providing the application which explains and reproduces this (attached to this message) note that the modal form must be opened the second time to see the bug.
Now, In Windows with gtk2 test it did not reappear! Is it a Linux bug?
It should be tested on Linux + qt combination. The line CheckBox.Color := clBtnFace prevents the bug and does not spoil the check box's appearance. Thats why this IFDEF is there. Here, I'll leave IFNDEF WINDOWS for now.

The second IFDEF is in DateEditorKeyDown procedure. On gtk2 (doesn't matter Windows or Linux), the CheckBox.SetFocus method seems to automatically generates one click. On win ws it is not so. I'll put IFDEF LCLWin32. Can you test it on qt, please? Should it be IFNDEF LCLGtk?

The third IFDEF is in DropDownCalendarForm procedure.
If the control is on a form shown modally then the calendar form cannot get user interaction unless it is shown modally too. It is a gtk2 behaviour, regardless of OS. Should be tested on qt, I'll put IFNDEF LCLWin32 for now.

By the way, can you tell me where can I see the list of all possible IFDEF's? 

[Zoran]

2.Handling calendar click (closeCalendarForm) isn't ok (calendarMouseUp()).
 Under qt ws, dateChanged()->LCL is passed after click (QEventMouseRelease), so if you close calendar from MouseUp event, qt calendar doesn't have enough time to change date and send signal which will be processed by LCL, so with one click, date in datepicker edit controls stays unchanged.
My proposal would be to handle Calendar.OnChange(SO YOU CAN CLOSE FORM HERE), with saved variable for hitTest() inside MouseUp.Only way I can get date change via TCalendar with qt ws is to navigate with keys and then press space (qt fires dateChange() -> LCL) and then click (closes calendar form and got right date).

Tomorow, it's too late now.

[Zoran]

3.Also direct date editing should be more flexibile, like in TMaskEdit. eg I cannot write 01 for date (leading

zero), it's automated, but confuses user.

I fixed it. It now behaves same as Delphi control.

[Zoran]

2.Handling calendar click (closeCalendarForm) isn't ok (calendarMouseUp()).

As you proposed, I moved the CloseCalendarForm call from calendar's MouseUp to calendar's OnChange.

This doesn't work on other widget sets because OnChange gets called earlier. Therefore I added IFDEF LCLQt. Please, test it on qt now.

[zeljko]

As you proposed, I moved the CloseCalendarForm call from calendar's MouseUp to calendar's OnChange.

This doesn't work on other widget sets because OnChange gets called earlier. Therefore I added IFDEF LCLQt. Please, test it on qt now.

uf uf .... than I have to change that order somehow inside qt ws (but first I'll take a look how does it work inside delphi - I mean event order). You tested win32 & gtk2 ?

[zeljko]

fyi, qt works same as TCalendar from Delphi 7 (both VCL and CLX). So, gtk2 implementation is wrong.
Correct order is OnClick() -> OnChange(), so better put LCLgtk2 ifdef's as workaround, because I'll fill an issue about this ,and it will be fixed one day.

[zeljko]

here is issue about gtk2 wrong event order:
http://bugs.freepascal.org/view.php?id=15682

[Zoran]

This is the order on win32: OnChange, OnClick, OnMouseUp.
If this order of events is wrong, this bug aplies not only to gtk2, but also to win32.

On both win32 and gtk2, calendar's OnChange is called before OnMouseUp. Therefore, IFDEF LCLQt remains.

So, the control works well now on qt too, doesn't it?

[zeljko]

Haven't test yet, trying to find out how to fix that bug for gtk2.If win32 also have same order than it's wrong (in comparision with Delphi).