Sieben: Thank you very much for the code, but what is Fsuspended, is a variable boolean?
if I have edit1.clear on event form OnActivate, it's is executed.I agree that triggering OnActivate by the DateTimePicker should be avoided (although I am not sure whether this is possible). But what you are saying here indicates bad design, don't clear an Edit control in OnActivate: When you open a second form OnActivate will be called, too, and erase your edit. The same will happen when your for contains another nonmodal form which you activate and you return to the starting form. Put initialization code into OnCreate, or call it from the routine which activated this form. Don't say "This does not apply to me" - who knows what you are doing in a year when you forgot all the details of this project?
Put initialization code into OnCreate, [...]
One small gotcha of those workarounds is that you should make sure the fields start with a known value, so you have to add an OnCreate event handler and initialize them:In Delphi one could rely on any class vars to be initialized with zero, so explicitely initializing strings to '', integers to 0 or Booleans to false wasn't really necessary. Different with Lazarus...?
Quote from: lucamarOne small gotcha of those workarounds is that you should make sure the fields start with a known value, so you have to add an OnCreate event handler and initialize them:In Delphi one could rely on any class vars to be initialized with zero, so explicitely initializing strings to '', integers to 0 or Booleans to false wasn't really necessary. Different with Lazarus...?
Please report it in bugtracker (http://bugs.freepascal.org/view_all_bug_page.php?project_id=1).
The fact that using the OnActivate is bad design practice does not mean that the DateTimePicker should activate the OnActivate of the Form.
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.
Quote from: ZoranNo, 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.
Quote from: ZoranNo, sorry, I disagree with that idea.For any particular reason...?
Feel free to create yet another date/time editor.
As far as I can see -- the "solution" will probably be just documenting this.
Oh no, I really like TDateTimePicker, and definitely prefer it to TDateEdit/TTimeEdit.Me too! I like the TDateTimePicker, thanks Zoran!
Just another short question while you're here: how about adding Alignment property...?
, but as I see now how it is implemented in TLabel and TEdit, the behaviour is not consistent:
Just to be sure -- You mean text alignment ...
I don't know; Is text alignment really needed?
Quote from: ZoranJust 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.QuoteI don't know; Is text alignment really needed?
Needed? No. I just thought taCenter would be nice to have, that's all.
_____________
|23/11/2020 | v |
------------------------
_________________
| 23/11/2020 | v |
------------------------
Do you really...? DirectInput is a property used for example with TFileEdit or TDirectoryEdit to prevent the user from directly entering text into the edit portion of the control but to force him to use the buttons and the dialogs behind them. In case of TDateTimePicker the calendar controls, the UpDowns or the wheel. Defaults to True (direct input allowed) but can be set to False. Not really 'needed' as well...
_____________
|23/11/2020 | v |
------------------------
_________________
| 23/11/2020 | v |
------------------------
Actually, forget it.
This should be common to all controls.
Try setting BorderSpacing.InnerBorder property to value greater than zero.
Try setting BorderSpacing.InnerBorder property to value greater than zero.
Thanks, it works.
Unfortunately, other controls don't follow the same rules.
There is no pattern about desing native controls?
Do you really...? DirectInput is a property used for example with TFileEdit or TDirectoryEdit to prevent the user from directly entering text into the edit portion of the control but to force him to use the buttons and the dialogs behind them. In case of TDateTimePicker the calendar controls, the UpDowns or the wheel. Defaults to True (direct input allowed) but can be set to False. Not really 'needed' as well...