Lazarus
Announcements => Third party => Topic started by: Zoran on January 31, 2010, 09:55:16 pm
-
Delphi's VCL has a control TDateTimePicker.
For editing dates LCL has TDateEdit instead. It does not have TDateTimePicker, because it uses native Windows control which does not exist on other platforms.
I prefer VCL's TDateTimePicker, so I created new TDatePicker control.
I tried to create a control which would resemble TDateTimePicker as much as possible. It behaves very much like VCL's control, but derives from TCustomControl and does not use native win control.
I created it on Windows XP with win widget set, but did some test on Ubuntu 9.10 with gtk2 also.
The package DateControls which contains TDatePicker and TDBDatePicker (a data-aware version of the control) can be downloaded here: http://datepicker.000space.com
EDIT: There is now new TZVDateTimePicker control, which completely covers the behavior of TDatePicker. The main advangate is time editing, so you should use it instead. See: http://www.lazarus.freepascal.org/index.php/topic,8754.0.html
-
It worked perfectly in Linux (Ubuntu 9.10/GTK2).
Thank you very much! :D
-
Does not compile under Windows Vista because of these lines:
Canvas.TextStyle.Layout := tlCenter;
Canvas.TextStyle.Wordbreak := False;
Canvas.TextStyle.Opaque := False;
The compiler gives the following error message
C:\Lazarus\components_extra\DateControls\datepicker.pas(1239,19) Error: Argument can't be assigned to
What can I do to correct this error?
-
Confirm assigning Canvas.TextStyle gives an error, I use the latest laz snapshot. fpc 2.4.1
-
On Widows XP it works perfectly. It sounds very strange to me that such a problem appears in Vista. I'm at work now and very busy, I'll look into code to try to change that part of code to something else this evening (central european time).
And yes, I use Lazarus 0.9.28.2, fpc 2.2.4 (the current stable version of Lazarus). Could problem be related to some recent changes in Lazarus/FPC, not to OS? I guess, I'll have to install new snapshot this evening.
-
I tried to install the component on Windows XP this morning & I got the same error message on the same lines related to
Canvas.TextStyle
I use Lazarus 0.9.29 fpc 2.3.1 of 01/01/2010.
-
I tried to install the component on Windows XP this morning & I got the same error message on the same lines related to
Canvas.TextStyle
I use Lazarus 0.9.29 fpc 2.3.1 of 01/01/2010.
So, the problem is probably related to some changes in Lazarus or FPC, not OS. I'll install new snapshot and see.
-
I tried to install the component on Linux Mint this morning & I got the same error message on the same lines related to
Canvas.TextStyle
Lazarus 0.9.29 FPC 2.5.1 Code Typhon Version
-
So, the problem is probably related to some changes in Lazarus or FPC
http://wiki.freepascal.org/User_Changes_2.4.0#Treating_direct-mapped_properties_as_regular_fields
-
So, the problem is probably related to some changes in Lazarus or FPC
http://wiki.freepascal.org/User_Changes_2.4.0#Treating_direct-mapped_properties_as_regular_fields
Thank you, Theo!
The solution was quite simple, I introduced a variable of TTextStyle type, then all assignments go to it, instead of Canvas.TextStyle. Then changed simple version of TextRect to longer (http://lazarus-ccr.sourceforge.net/docs/lcl/graphics/tcanvas.textrect.html), with TextStyle. That was all. I updated the link, please download it again, it should work now.
-
I can confirm that it now works. Thanks.
-
@Zoran It would be nice to extend this component to WS part, so why not call it TDateTimePicker, and allow date, time or date & time editing.
For basic functionality it can edit dates only (like you made it - and it doesn't have to be implemented in ws which does not support it), but win32 or qt ws on mac,linux & win have such funcionality and can be fully useable (don't know for carbon or gtk2 but think that there must be such ctrls).
-
@Zoran It would be nice to extend this component to WS part, so why not call it TDateTimePicker, and allow date, time or date & time editing.
For basic functionality it can edit dates only (like you made it - and it doesn't have to be implemented in ws which does not support it), but win32 or qt ws on mac,linux & win have such funcionality and can be fully useable (don't know for carbon or gtk2 but think that there must be such ctrls).
Unlike most standard controls (like edit boxes, check boxes or buttons), the native date editing control either does not exist or look and interact with user quite differently on different widget sets. On gtk2, as far as I know, there is no similar control. I don't know anything about other widget sets.
I beleived that many Lazarus users have Delphi background and would like to have the control which looks and feels like VCL's TDateTimePicker, but which would be cross-platform.
Having these things in mind, my intention was therefore to create a Delphi's TDateTimePicker cross-platform clone.
I thought that the best aproach would be to provide a control which would not rely on any native control. I wanted a control which would appear same and interact with a user same on all platforms.
Yes, my control lacks time editing feature. I beleived that the date editing is more needed, so I saw providing this functionality as my first priority. I achieved to have the control act on user interaction same as VCL's control when used for dates, which was my primary aim. The user just cannot input invalid dates.
Furthermore, I extended the functionality to null date value (esspecialy useful when dealing with databases). I think that I acheived the functionality that is most needed. I admit that I would like to see time editing possible.
To summarise -- the purpose of this control is to have one control, totally cross-platform, with same appearance and same functionality on any platform.
So, as the next step I would rather see extending functionality to time editing, but without using native widgets, I don't think that, for this control, going into ws parts would be a good idea.
-
@Zoran, your ctl is very nice and I don't wanna say that something is wrong with it - good start and also I would like to see it in lazarus components ASAP + of course ability to edit time also :)
My idea wasn't to go in the ws direction just because of ws, but because of users which expect same behaviour on OS they use.If you can reach same behaviour as native one than fine :) gtk2 maybe doesn't have such control, but win32, qt (on all supported platforms) and carbon (think so) have such control.
zeljko
-
@Zoran, your ctl is very nice and I don't wanna say that something is wrong with it - good start and also I would like to see it in lazarus components ASAP + of course ability to edit time also :)
My idea wasn't to go in the ws direction just because of ws, but because of users which expect same behaviour on OS they use.If you can reach same behaviour as native one than fine :) gtk2 maybe doesn't have such control, but win32, qt (on all supported platforms) and carbon (think so) have such control.
zeljko
That is exactly how I understood what you meant in the first place. :)
Sorry, I missed to say that I agree with you that extending the control the way you suggested is a nice thing to do, for people who would preffer the control which acts natively on different platforms, it would be nice to provide such behaviour.
I just wanted to point out that same appearance and behavior on different platforms can be prefered and seen as an advantage.
That's what I had in mind when designed this control. I just wanted it to act and appear as much same as Delphi's control as possible on all platforms. I'm still sure that many people want to be able to use old Delphi's control in their programs, and want their application to look as much same as possible when compiled on Linux or Windows.
I would prefer it so.
So... we need two controls. :)
With time editing functionality, of course. ;)
-
Please, testing on other platforms is needed.
So far it's tested on Windows and Linux with gtk2.
Can someone try it on Mac?
-
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.
-
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.
-
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
-
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 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
-
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? :)
-
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.
-
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.
-
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.
-
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 ?
-
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.
-
here is issue about gtk2 wrong event order:
http://bugs.freepascal.org/view.php?id=15682
-
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?
-
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).
-
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).
Actually, in Delphi's TMonthCalendar there is no OnChange event at all (http://docwiki.embarcadero.com/VCL/en/ComCtrls.TMonthCalendar_Members)!
So I'd say it cannot occure neither before nor after OnClick. ;)
Or I'm missing something.
-
I've tested TCalendar from Delphi 7
-
I've tested TCalendar from Delphi 7
I have Delphi 6 and there is no control TCalendar, but only TMonthCalendar, which does not have OnChange event.
Now, on Delphi's official site, again, only TMonthCalendar is there (http://docwiki.embarcadero.com/VCL/en/ComCtrls.TMonthCalendar), and again there is no OnChange.
So, it sounds very strange that in Delphi 7 it was different!?
-
dunno, I have D7 enterprise and that control is on component pallete (installed by default)
-
However, we should see in Delphi is the date actually changed before or after OnClick gets called.
I just tested in Delphi -- in OnClick event the Date is already changed!
Therefore, I'd say that TCalendar's event order should be -- OnChange before OnClick, as it is now in gtk2 and win32 widgetsets.
-
Then Delphi7 TCalendar is wrong. I'll change qt event order so it will be the same like others.
-
dunno, I have D7 enterprise and that control is on component pallete (installed by default)
Are you using CLX maybe? Not VCL?
VCL's component is named TMonthCalendar and it behaves like I described.
-
no, I've tested with TCalendar from VCL, CLX doesn't have such control, but forget it , I've already prepared patch for qt ws (currently testing on mac), and it'll be reorderd as it is with win32 and gtk2.
-
no, I've tested with TCalendar from VCL, CLX doesn't have such control, but forget it , I've already prepared patch for qt ws (currently testing on mac), and it'll be reorderd as it is with win32 and gtk2.
Okay, I see that you assigned the bug to yourself and targeted 0.9.30 Lazarus version to change the qt's calendar event order.
Is there IFDEF which can be used to examine Laz version? So that I can put something like IFDEF LCLQt and IFDEF LazVer < 0.9.30?
-
Yes. Example:
{$if (lcl_major=0) and (lcl_minor=9) and (lcl_release<27)}
Result := LConvEncoding.GetSystemEncoding;
{$else}
Result := LConvEncoding.GetDefaultTextEncoding;
{$endif}
http://lazarus-ccr.sourceforge.net/docs/lcl/lclversion/index.html
-
Okay, I see that you assigned the bug to yourself and targeted 0.9.30 Lazarus version to change the qt's calendar event order.
Is there IFDEF which can be used to examine Laz version? So that I can put something like IFDEF LCLQt and IFDEF LazVer < 0.9.30?
But it won't be enough since it's fixed in 0.9.29 svn r 23641 , so svn revision should be taken into account somehow, or qt version will be unuseable till lazarus reaches 0.9.30
-
Yes. Example:
{$if (lcl_major=0) and (lcl_minor=9) and (lcl_release<27)}
Result := LConvEncoding.GetSystemEncoding;
{$else}
Result := LConvEncoding.GetDefaultTextEncoding;
{$endif}
http://lazarus-ccr.sourceforge.net/docs/lcl/lclversion/index.html
Thank you.
Okay, I see that you assigned the bug to yourself and targeted 0.9.30 Lazarus version to change the qt's calendar event order.
Is there IFDEF which can be used to examine Laz version? So that I can put something like IFDEF LCLQt and IFDEF LazVer < 0.9.30?
But it won't be enough since it's fixed in 0.9.29 svn r 23641 , so svn revision should be taken into account somehow, or qt version will be unuseable till lazarus reaches 0.9.30
Hm... then I'll put lcl_revision < 29. So, the component will have problems on qt with 0.9.29 when svn revision is smaller than that. It will always work on 0.9.28 and 0.9.30. Given that 0.9.29 is not "stable" version, you are just expected to have the newest daily svn. That's the best option I came up with.
-
I agree with you. Just check >= 0.9.29 and that's it.
....and tnx :)
-
I agree with you. Just check >= 0.9.29 and that's it.
It's done.
....and tnx :)
Thank you!
Without your help, I doubt this control would ever be fully functional for qt users. :)
-
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
What should I do? Where to put the code? I found some free web hosting and put it there, but I would prefer it to be as close as possible to Lazarus users.
It took me four days to figure out how to start new page on Wiki (which I finally did yesterday) (http://wiki.lazarus.freepascal.org/DateControls_Package_for_Lazarus). :-[
-
We'll if you want it ASAP than lazarus-ccr should be the best place (but dunno who can be contacted about it), lazarus/components need some time that core developers decide to put it in or not.
-
@Zoran
You can contact Vincent Snijders.
You will need an SourceForge account
Take a look at http://wiki.lazarus.freepascal.org/Using_the_Lazarus-ccr_SVN_repository
-
There is now new TZVDateTimePicker control, which completely covers and improves the behavior of TDatePicker. The main advangate is time editing. See: http://www.lazarus.freepascal.org/index.php/topic,8754.0.html