Hello,
I encountered two issue while using TPlannerMaskDatePicker:
- The more serious one is, that if the component is modified and empty, you can't leave it. For example if you simply put it on a form, open the form, select the component, type something and then delete everything, it is impossible to change the focus, which is very awkward.
- If you add a bitmap containing more than one glyph as a glyph, only the first one is recognized. The usual button-handling of glyphs doesn't seem to be implemented ("numglyphs" exists, but doesn't seem do anything). Normally you can just load a bitmap with two glyphs and you've got the correct behavior with enabled/disabled.
- Unfortunately doesn't work this way. I managed to supress the undesired behavior by setting "modified = false" in the KeyUp-event, but that is a rather cumbersome workaround. Interestingly the DB-variant of the component behaves correctly and doesn't require a workaround.
- Doesn't work either. I might be overseeing something but "numglyphs" doesn't seem to be used for anything in the source code.
At this opportunity, I also encountered two issues with TPlannerDBMaskDatePicker:
- If the current underlying date-field has a value and you perform an append or insert on the dataset, then the component still displays the value of the former record although the current value in the new record would have to be NULL. Changing records with next/prior works though.
- While editing the component often flickers. It seems that the former value of the component is displayed for a very short time when it flickers.
For 2, this works as expected:
begin
SpeedButton1.NumGlyphs := 2;
SpeedButton1.Glyph.LoadFromFile('e:\tms\temp\numglyphs2.bmp');
PlannerMaskDatePicker1.ButtonStyle := bsButton;
PlannerMaskDatePicker1.Button.NumGlyphs := 2;
PlannerMaskDatePicker1.Button.Glyph.LoadFromFile('e:\tms\temp\numglyphs2.bmp');
end;
I have attached the bitmap I am using.
I am basically now doing the same thing:
- I put a TPlannermaskdatepicker and a TSpeedButton on a form.
- I am using the exact same source code as you do preset both components
- I now add another button which when clicked simply disables/enabled both components
- In my case the SpeedButton switches between both glyphs whereas the PlannerMaskDatePicker only displays the first glyph, regardless of whether it is enabled or disabled.
DateGlyph.zip (305 Bytes)
I took another look at the flickering-issue and realized that there is a catch to it:
The component only flickers when you set the EditMask-attribute.
I for example use the following:
PlannerDBMaskDatePicker1.EditMask := '!90/90/0000;1;_';
If you set the EditMask and then start editing the component while it is connected to a data-record, it will flicker from time to time, which means that it will very briefly display a different date instead of what you are typing.
It is very obvious if you repeatedly type and delete one number in quick succession: You will very briefly see another date displayed, which seems to be the current field-value of the data-record. In my case the field-value was NULL, so it would flicker to '30.12.1899'.
On a sidenote I just found another strange behavior from PlannerDBMaskDatePicker:
If you type in the incorrect date "12.15.2024" (we are using the format dd.mm.yyyy), the component will "autocorrect" it to "15.12.2024", which is a bit awkward because it may allow people to enter a false date without noticing it as it is not given that they wanted to enter "15.12.2024" in this case.
The culprit seems to be the internally used "VarToDateTime", which for some reason turns "12.15.2024" into "15.12.2024" instead of complaining.
VarToDateTime is a standard Delphi RTL function that is the most flexible one in terms of supporting date formats. We see no easy replacement for this function with an equivalent functionality.
The last patch resolved the insert issue and the glyph problem. The flickering is still there.
There is however a new phenomen:
In several forms of my program, when I perform an insert on a TFDQuery, that has an PlannerDBMaskDatePicker attached to its Datasource, afterwards it will display the NULL-value "29.12.1899".
The funny thing is however that after the insert the date field is not NULL, but already has got the value "29.12.1899". There are no events that are doing this, in fact when I set an AfterInsert and check with the debugger, then it already has that value when reaching OnAfterInsert.
That is not the case on every form, there are some where it works normal, but at this stage I haven't found a discrepancy that could explain it.
The only thing I know is that with an program version from shortly before the component patch, this was not the case.
Did something change with the component's insert-behavior that could explain that? I am currently at a loss as to how that date value is applied after an insert and why that isn't the case everywhere.
I could not reproduce this. Test project is attached.
Project1.zip (63.1 KB)
I am trying to reproduce it in a test projekt but so far I am failing to do so.
What I realized however is that "29.12.2024", the value I talked about, obviously isn't the NULL-value but rather -1.
if (FDataLink.DataSet.State = dsInsert) {and (FOldState <> dsInsert)} then
begin
dt := FDataLink.Field.AsDateTime;
if Int(dt) <> 0 then
self.Date := dt
else
begin
self.Date:= -1;
self.Text:= '';
end;
end;
The else-part was added with the patch. When I remove this part, the problem vanishes. When I instead change the new part to "Self.Date:= 0;", it vanishes as well.
So in my case for some reason the date-value -1 is written into the attached date field after an insert under certain circumstances.
I am trying to find out what these circumstances are (as said there are no events), but does the date have to be set to -1 instead of 0 in this instance?
I would appreciate if you can send a test projects with which we can reproduce this so we can investigate this.
I finally found it:
The special case in which this problem occurs is when you have two or more TPlannerDBMaskDatePickers accessing the same data field.
This seems to trigger additional internal data change events which cause the -1 to be written.
I've attached a sample unit that shows the issue: Two TPlannerDBMaskDatePickers with the same datafield. Once you press the button to perform an insert, one of the datepickers will now display "29.12.1899".
DatePickerExample.zip (3.9 KB)
Was the testproject sufficient for the purpose of reproducing the issue?
We could trace & solve this issue. The next update will address this.