Recent

Author Topic: Problem with DateTimePicker  (Read 1467 times)

Zoran

  • Hero Member
  • *****
  • Posts: 1610
    • http://wiki.lazarus.freepascal.org/User:Zoran
Re: Problem with DateTimePicker
« Reply #15 on: November 21, 2020, 01:53:28 pm »
I see, I get it now. The closing of DateTimePicker's calendar form triggers the activation of DateTimePicker's parent form.

I'll try to see if I can do something. I would like to solve it, but I am not sure if it is possible. Perhaps some workaround can be found...

It seems that other custom controls which show drop-down form also suffer from this (I have just tested DateEdit -- same problem).

Please report it in bugtracker.

Zoran

  • Hero Member
  • *****
  • Posts: 1610
    • http://wiki.lazarus.freepascal.org/User:Zoran
Re: Problem with DateTimePicker
« Reply #16 on: November 21, 2020, 02:11:16 pm »
Please report it in bugtracker.

I see you already did (Bug 38108).
Thank you for reporting!

greenmask

  • Newbie
  • Posts: 4
Re: Problem with DateTimePicker
« Reply #17 on: November 21, 2020, 03:39:01 pm »
A few hours ago I reported the bug in LazarusBugTracker, a developer agrees with the DateTimePicker problem, although they also emphasize that it is bad design to use the OnActivate event.

I agree with what was said about a bad design, however perhaps because of that bad practice of including initialization code in the OnActivate I saw the problem.

1. In a Form1, you put an Edit1, Edit2, DateTimePicker1.
2. In the onActivate event of the Form you write an Edit1.clear; Edit2.clear;
3. You run.
4. You enter something in edit1 and edit2.
5. You select any date.

With these steps you can see that the Edits (Edit1,edit2) are immediately cleaned up because onActivate was activated. Selecting a date in the DateTimePicker calls the onActivate and executes some code that is there.

The fact that using the OnActivate is bad design practice does not mean that the DateTimePicker should activate the OnActivate of the Form.

Greetings to all and thanks for responding. Blessings.

OS Linux Mint 19.1 Tessa 64 bits - Lazarus 2.0.10 - fpc 3.2.0

Zoran

  • Hero Member
  • *****
  • Posts: 1610
    • http://wiki.lazarus.freepascal.org/User:Zoran
Re: Problem with DateTimePicker
« Reply #18 on: November 21, 2020, 04:42:53 pm »
The fact that using the OnActivate is bad design practice does not mean that the DateTimePicker should activate the OnActivate of the Form.


I fully agree with that, as I said in that report.

As I also said, the only clean solution would be to prevent stealing of focus from the parent form in the first place.

However, I doubt that it is possible. The built-in controls, like Combo boxes and pop-up menus can do it, but I don't think that a custom control can show some kind of a pop-up window other way than creating a separate form, which then the application will treat just like that - a separate form. So, when the pop-up form receives focus, the original parent form of the main control loses focus - this will trigger OnDeactivate event - and when the focus is returned to the main control, its parent form gets focus again - this will trigger OnActivate.

I would like some workaround, but the fact that the other custom controls which also show their own pop-up forms non-modally have the same problem doesn't look promising...

wp

  • Hero Member
  • *****
  • Posts: 7750
Re: Problem with DateTimePicker
« Reply #19 on: November 21, 2020, 04:51:16 pm »
Instead of adding the popup calendar to a form, can't you add it to a panel? There could be code to hide (destroy?) the panel when the user clicks on a calendar date, tabs out of the calendar, presses ENTER. I do see a problem, though, when the user clicks outside the calendar or even outside the parenting form because in this case the click events will not be passed to the calendar.
Mainly Lazarus trunk / fpc 3.2.0 / all 32-bit on Win-10, but many more...

Zoran

  • Hero Member
  • *****
  • Posts: 1610
    • http://wiki.lazarus.freepascal.org/User:Zoran
Re: Problem with DateTimePicker
« Reply #20 on: November 21, 2020, 06:46:02 pm »
Instead of adding the popup calendar to a form, can't you add it to a panel? There could be code to hide (destroy?) the panel when the user clicks on a calendar date, tabs out of the calendar, presses ENTER. I do see a problem, though, when the user clicks outside the calendar or even outside the parenting form because in this case the click events will not be passed to the calendar.

No, sorry, I disagree with that idea.

Another (less aggressive) "solution" is to show the calendar modally (see bellow*), but I would disagree with that too.

I think that it would be much worse than, if nothing else can be done, just document that behaviour as a "non-solvable" bug (something like this).
Something like -- Be aware that form's OnDeactivate and OnActivate events will fire each time the calendar is dropped down and closed.

Please notice that other custom controls which show pop-up window non-modally suffer from this problem too (for example TDateEdit).

(*) Custom controls that show pop-up window modally do not trigger OnDeactivate and OnActivate (for example TCalcEdit)!



Sieben

  • Full Member
  • ***
  • Posts: 144
Re: Problem with DateTimePicker
« Reply #21 on: November 21, 2020, 08:04:05 pm »
Quote from: Zoran
No, sorry, I disagree with that idea.

For any particular reason...? What about storing and restoring the owner form's event handler when switching focus? Although I feel I don't know enough of the caveats of the underlying widgetsets etc to judge if this would be a way to go or not.
Lazarus 2.0.10, FPC 3.2.0, .deb install on Ubuntu Xenial 32

Zoran

  • Hero Member
  • *****
  • Posts: 1610
    • http://wiki.lazarus.freepascal.org/User:Zoran
Re: Problem with DateTimePicker
« Reply #22 on: November 21, 2020, 09:06:42 pm »
Quote from: Zoran
No, sorry, I disagree with that idea.

For any particular reason...?

The panel? In my opinion, with this so different approach, it won't be DateTimePicker anymore.
There are many obstacles with this; first -- where and how to position it on the form?

This can be a new control. Fill free to create yet another date/time editor.
Well, it can have its place, some could prefer it to currently existing alternatives (TDateTimePicker, TDateEdit, TTimeEdit -- all with pop-up form approach). I would not.

But come on, if the reason for taking this approach is just this problem with focus, then no; I really can't think it's worth it.

What about storing and restoring the owner form's event handler when switching focus? Although I feel I don't know enough of the caveats of the underlying widgetsets etc to judge if this would be a way to go or not.

Of course, that is the idea, well, sort of...
I am experimenting with hooking parent's form WndProc, but... the results don't look promising for now -- in short, it looks like deactivate part might be solved, but activating not, there it seems that LM_ACTIVATE doesn't seem useful -- it is sent too late (depending on how the calendar gets closed, it can be before of after deactivate of calendar form). LM_SETFOCUS is more promising, it is sent when calendar is still active, but there also I cannot see a straightforward solution -- I need to be sure when it is called and remember it somewhere (provided the calendar form is active); but then a reliable place to restore old WndProc is needed. The order and the appearance of these messages doesn't look very reliable.
Anyway, it needs a lot of testing. And in all main widgetsets of course. Plus I cannot test on Mac.

In short -- don't expect much.
As far as I can see -- the "solution" will probably be just documenting this.

lucamar

  • Hero Member
  • *****
  • Posts: 3236
Re: Problem with DateTimePicker
« Reply #23 on: November 21, 2020, 09:16:27 pm »
Quote from: Zoran
No, sorry, I disagree with that idea.
For any particular reason...?

Here is a particular reason: if, like in most even semi-serious apps, you have a carefuly laid out form using anchors, control alignment, etc. having a panel pop-up in there has the extremely likely potential of disrupting everything  until it's again closed (and might not be restored even then). You need something that is almost completey outside the form (in this respect), and that's basically another, overlaid form.

It's not easy to deal with this problem.
« Last Edit: November 21, 2020, 09:18:29 pm by lucamar »
Turbo Pascal 3 CP/M - Amstrad PCW 8256 (512 KB !!!) :P
Lazarus/FPC 2.0.8/3.0.4 & 2.0.10/3.2.0 - 32/64 bits on:
(K|L|X)Ubuntu 12..18, Windows XP, 7, 10 and various DOSes.

Sieben

  • Full Member
  • ***
  • Posts: 144
Re: Problem with DateTimePicker
« Reply #24 on: November 21, 2020, 09:46:19 pm »
Thank you both for explanations, I was just curious re the TPanel approach.

Quote from: Zoran
Feel free to create yet another date/time editor.

Oh no, I really like TDateTimePicker, and definitely prefer it to TDateEdit/TTimeEdit.

Quote
As far as I can see -- the "solution" will probably be just documenting this.

Fine with me. And there always is the workaround with the form flag laid out earlier in this thread.

Just another short question while you're here: how about adding Alignment property...?
Lazarus 2.0.10, FPC 3.2.0, .deb install on Ubuntu Xenial 32

Eleazar

  • New Member
  • *
  • Posts: 17
Re: Problem with DateTimePicker
« Reply #25 on: November 21, 2020, 11:42:03 pm »
Oh no, I really like TDateTimePicker, and definitely prefer it to TDateEdit/TTimeEdit.
Me too! I like the TDateTimePicker, thanks Zoran!

Zoran

  • Hero Member
  • *****
  • Posts: 1610
    • http://wiki.lazarus.freepascal.org/User:Zoran
Re: Problem with DateTimePicker
« Reply #26 on: November 22, 2020, 12:03:27 am »
Just another short question while you're here: how about adding Alignment property...?

Just to be sure -- You mean text alignment (which will override BidiMode, like CalAlignment overrides BidiMode)?
Currently, text alignment is controlled by BidiMode only (try it, but to see it, first set AutoSize to false and make the control wider).

I could add it, but as I see now how it is implemented in TLabel and TEdit, the behaviour is not consistent:
TLabel:
when BidiMode = bdRightToLeft, then everything is contra - when Alignment = taLeftToRight then the text is aligned to right side of the control and when taRightToLeft then to the right side
TEdit:
when BidiMode = bdRightToLeft, the text is aligned to right side, with both taLeftToRight and taRightToLeft.

In both these controls, when Alignment = taCenter, then BidiMode is ignored (as expected).

And in both controls, when BidiMode is bdRightToLeftNoAligned or bdRightToLeftReadingOnly, then they behave like bdLeftToRight. I don't understand what these are for.

I'd say, TEdit behaviour is probably a bug. However, I'm not satisfied with the way TLabel behaves either.
I would rather have taLeading and taTrailing added to this enumeration, which would behave like TLabel behaves with taLeftToRight and taRightToLeft respectively (they would follow BidiMode). Then, taLeftToRight and taRightToLeft would override BidiMode behaviour. And taLeading would be the default.

I could add a new enumeration in DateTimePicker for this Alignment property... However, I don't like not to follow the defaults...

Delphi's control does not have this property either.
But we are better than Delphi, of course (except for small inconvenience with focus ;) ).
I don't know; Is text alignment really needed?
« Last Edit: November 22, 2020, 12:05:30 am by Zoran »

Zoran

  • Hero Member
  • *****
  • Posts: 1610
    • http://wiki.lazarus.freepascal.org/User:Zoran
Re: Problem with DateTimePicker
« Reply #27 on: November 22, 2020, 12:08:35 am »
, but as I see now how it is implemented in TLabel and TEdit, the behaviour is not consistent:

I reported it: bug 38112

Sieben

  • Full Member
  • ***
  • Posts: 144
Re: Problem with DateTimePicker
« Reply #28 on: November 22, 2020, 02:58:14 pm »
Quote from: Zoran
Just to be sure -- You mean text alignment ...

Yes, taLeftJustify, taRightJustify and taCenter. I have to admit that I never played around with combinations of Alignment and BiDiMode - but behaviour of TEdit is in fact peculiar.

Quote
I don't know; Is text alignment really needed?

Needed? No. I just thought taCenter would be nice to have, that's all.
Lazarus 2.0.10, FPC 3.2.0, .deb install on Ubuntu Xenial 32

Zoran

  • Hero Member
  • *****
  • Posts: 1610
    • http://wiki.lazarus.freepascal.org/User:Zoran
Re: Problem with DateTimePicker
« Reply #29 on: November 22, 2020, 11:36:57 pm »
Quote from: Zoran
Just to be sure -- You mean text alignment ...

Yes, taLeftJustify, taRightJustify and taCenter. I have to admit that I never played around with combinations of Alignment and BiDiMode - but behaviour of TEdit is in fact peculiar.

Quote
I don't know; Is text alignment really needed?

Needed? No. I just thought taCenter would be nice to have, that's all.

Okay. Alignment property added in rev. 64155. Behaves like TLabel.

 

TinyPortal © 2005-2018