TParamTreeView TIME doesn't keep entered time

[Saunders_Karen]

I'm struggling to use TParamTreeView with TIME parameter in current versions of VCL UI Pack - I'm relatively confident it used to work, but do not currently have any evidence of this.

This can be demonstrated easily enough just with the component editor in the IDE.

• Invoke the component editor by double-clicking a TParamTreeView
• Add a new item and give it some markup like this: Logout time of the day: <a href="pAutoLogoutTime" class="TIME" hint="When is auto-logout?">00:00:00</a>
• Press the orange checkmark toolbutton to Update item
• Note the markup has been rendered so you can test it out, and the time currently shows 00:00:00
• Enter a new time in that 'sample rendering'
• Tab away
• exp: the entered time remains
• act: the time reverts to 00:00:00

I can use other parameter types perfectly fine, just not TIME

Please advise what I am doing wrong, or how to fix it.

Thanks!

[brunofierens]

I could not reproduce this.

[Saunders_Karen]

Which version of the control is that you are using? Mine is version 1.4.0.1 according to the Version property. If this is not current, have there been any fixes to this code since?

Also, did you try repro'ing it by following the steps, using the component editor?

[Edit]What markup did you use in your control? That may be key.[/Edit]

I shall try and upload a GIF showing what occurs for me

Thank you

[Saunders_Karen]

Here is what I see in the IDE, and the control's behaviour matches what I see at runtime. Can you come up with a reason for this, or how to avoid it?

[brunofierens]

It was not clear this referred to design-time editing. The design-time editor was not intended to edit the actual values. If you want to change the actual value, change it in the HTML for the item, i.e.

Logout time of the day: <a href="pAutoLogoutTime" class="TIME" hint="When is auto-logout?">15:30:00</a>

[Saunders_Karen]

@brunofierens

It was not clear this referred to design-time editing.

The steps I gave were relating to the component editor, as a simple way to demonstrate the problem I had. However, as stated, I have the exact same problem at runtime. The fact that the same symptom is demonstrated both at design time and at runtime was why I gave the design-time steps - it is easier to see there.

@brunofierens

The design-time editor was not intended to edit the actual values

OK, so I will come back with runtime steps to show the same issue I have in the app, and perhaps you can then help me identify how to use the control successfully?

[brunofierens]

I couldn't reproduce the problem at runtime here. Test is dropping the component on the form, add the node with HTML and compile & run the app and fill a time.

[Saunders_Karen]

@brunofierens

I couldn't reproduce the problem at runtime here

Yes, so I gathered. Nevertheless, I do and I would welcome assistance in working out why or how to not get it.

With your knowledge of your code base, can you conjure up a possible scenario where my behaviour occurs?

Please see runtime behaviour below. I know you cannot reproduce it, however I would welcome insights / thoughts about why I am experiencing it.

The HTML in my steps - that is correct I assume?

Thank you

[Saunders_Karen]

BTW, I asked someone else in my user group with this component suite to also try it. They have version 1.5.0.0 of the control and they get the same behaviour as me by following these steps:

• put a TParamTreeView on a form as well as another control that can take the focus, like a TEdit.
• double-click the TParamTreeView
• Add a new item and give it some markup like this: Logout time of the day: <a href="pAutoLogoutTime" class="TIME" hint="When is auto-logout?">00:00:00</a>
• Press the orange checkmark toolbutton to Update item
• Press the green checkmark to commit the changes to the component
• Run the app and enter a time in the TParamTreeView
• Click on the TEdit

Expected: entered time remains
Actual: time resets to 00:00:00

It seems it is not just my installation, which I think is quite important.

[Edit]

Someone else has tried it and can also repro the issue. So far you are the only one who cannot see the issue out of 4 separate installations. Of those that do see it, at least 2 are running Windows in UK locale etc.

[Saunders_Karen]

I would send you my compiled .exe (the one shown above), just so you can see the behaviour I see for yourself, but I do not think this support system supports .exe or .zip / .7z files

[Edit]

If need be, please pull my .exe from Project1.exe and compare the behaviour. If you still don't see the errant behaviour, then whatever control underlies the TIME parameter must behave differently based on some aspect of the Windows environment I would guess, but I have not dug into its code....

[Saunders_Karen]

Jason Chapman of the UK Dev Group looked at the issue and found the cause in parHTML.pas.

Lines 2922 and 2948 both have this code (or lines 2891 and 2917 in my older file - just search for the expression, which is found in TPopupDatePicker.WMActivate and TPopupDatePicker.WMKeyDown) : TimeToStr(Date) where Date is a property of a TDateTimePicker.

However Date is just the date part of the picker's date and/or time value, with a time part of 00:00:00. Changing both these to TimeToStr(Time) seems to address the issue.

Further investigation on my part shows that in Delphi 10.2.3 the implementation of TCommonCalendar.GetDate (the getter for TDateTimePicker's Date property) was:

Result := TDate(FDateTime);

that is the whole date including the time, just cast to the TDate type. However in 10.3.0 the implementation changes to:

Result := TDate(DateOf(FDateTime));

this cuts out the time part and leaves just the date part. As such, when built with Delphi 10.3.0 or later, the TIME parameter uses code (TimeToStr(Date)) that gets the string version of an empty time, which of course yields 00:00:00.

Fixing the code in parHTML.pas to use TimeToStr(Time) resolves the issue and allows your component to work for TIME parameters again in 10.3.0 and later.

For the time being, I am assuming that either you built your test app in 10.2.3 or earlier, or you have an updated version of parHTML.pas that none of us have?

Please confirm your thoughts on this assessment, and whether an official bug fix will be forthcoming, to avoid having customised TMS source files

I look forward to your reply

Thank you

[brunofierens]

As there was no Delphi version information in the original posts, it was not clear this was critical.
It indeed appears that Delphi newer versions broke this. We applied the fix and this will be included in the next update.