Component Pack 8.3.0.0 Delphi 10.1 Berlin Windows 7 x64
On the first mouse click on an edit field, the edit box pops up in the wrong place, a long way to the right of and below the link. If you try to edit the same field again, or double-click the field the first time, the edit box is positioned correctly over the link item.
This happens in the parameter controls demo (unmodified), and in the parameter editor in the IDE. It makes all these controls unusable.
Yes, clean install. I did not mention that i am using 120dpi and it could be the reason. I will try running the demo app on a VM I keep specially to vary the text size settings. This might be a Berlin issue since there are lots of reported issues with Berlin at other than 96dpi
No, it is not text size. There is no problem with the demo program on W10/64 at 100%, 125% or 150%. But the box is still misplaced on my main development system (W7/64 at 125%). I will investigate with a debugger!
I set a breakpoint in the 'EDIT' section of the StartParamEdit method. The value of pt is exactly the same on the first and second attempt to edit the field, but the box pops up in different places.
I have tested on Windows 10 and XP and the box position is always correct. But on Windows 7, it is always incorrect, on two separate physical machines and one virtual machine, all running Windows 7 Pro 64-bit. This is using the same EXE for all tests.
Final post today. The problem occurs when running on Windows 7 and the screen text size is not 100% and the form Scaled attribute is set. It does not occur when the screen text size is 100%, and it does not occur on Windows 10 at any text size. The development machine was running with the screen text size 125% when the demo program was built.
I believe that this is a well-known Berlin 10.1 issue where the DPI is recalculated incorrectly, but I had not seen this mispositioning effect before, or been caught by the VCL problem in any other applications, because we normally set Scaled off.
Sorry to waste your time on this, but hopefully the case may help someone else.
This indeed is related to an issue in the VCL itself. We have implemented a workaround for this though and this workaround will be included in the next update.
Thanks, I will look out for the update. But while we are on the subject of this component I have some general comments about the ParameterCheckList, some of which apply to the other parameter components also. I now have the parameter checklist behaving as I need it to, but it has been something of a struggle. I have the following observations which I hope will enable you to improve this component.
1. When you have 'comment' items in the list, as in your demo, it is extremely hard to tie up the simple NotifyEvent for CheckClick with the parameter href(s) to which it applies. I found it necessary to keep track of the comment lines to convert between the checkbox item index and the parameter index. The component badly needs a new OnCheckClick event which integrates properly with the parameters, like the other events.
2. The documentation is very confusing about the 'index' parameters. There is the control item index, the index of parameters, and other index items as well. It would be helpful to be consistent with different method parameter names for each one: currently the parameter documentation uses "Index: Integer" in every case, without mentioning which 'index' it is.
3. There are several typos in the documentation:
multiple "href: Integer"
The ParamProps definition fails to mention that it also used for toggles.
GetParamInfo omits the index parameter
The component has an interesting design and is very useful. But a little more care in the documentation and a little more thought about how the checkboxes will need to be used would make it even better.
I'm not sure I understand your remark. When a checkbox is clicked, the control.ItemIndex property indicates what checkbox was clicked, regardless of the list having comment items.
2. There can indeed be an index of items (TParamListBox, TParamCheckList) and an index of parameters itself within an item. We have made this more clear in the doc by now referring to ItemIndex and ParamIndex.
3. We have corrected references to href as being an integer to string.
4. The info about ParamProps was also updated to include the TOGGLE.
Next TMS Component Pack update will have this updated doc.
All good! My point in (1) is that in the current on-click event, I am passed the itemindex in the control. But I ALWAYS need to know the parameter that has been check-clicked (I only have one href per line), It would be good if there was an href parameter for the onclick event, because the paramindex is offset by the number of preceding comments, so needs work to use.
To accommodate users who have multiple parameters per check-list item, the oncheckclick event could be passed an "hrefs" of the form 'href1|href2', or an array. Then it would be simple to handle a check click and know immediately which parameter(s) it referred to.
My current workaround has been to add a new property to return the checklistbox itemindex for a parmindex value and call this in a loop at the start to build a lookup table of hrefs for each itemindex. This makes for easy maintenance if I add a parameter somewhere in the list, but is not very elegant. All the other events pass the href and/or paramindex, but checkclick is different.
I'm sorry but this message is confusing to me. You refer to OnClick (only Sender parameter) , OnCheckClick (only Sender parameter). If you want to detect clicks on parameter values in items, please use the OnParamClick. This returns as 2nd parameter the index of the item that contains the parameter (regardless of comment items) and the 3rd parameter is the href of the parameter value. When you click the checkbox of a checklist item, only OnCheckClick is triggered and with ItemIndex you can identify the item for which the checkbox was clicked.If from that event you want to do anything with the parameter values of that item, you can use ParamItemRefCount[ItemIndex] and loop through the item parameter values with ParamItemRefs[ItemIndex,ParamIndex]: string
Yes, apologies for my typo - I meant to refer only to the oncheckclick event. OnParamClick is fine. And yes, I know there are workarounds, either involving a loop or (as I have used myself) building a lookup table in advance. All I am pointing out is that since the whole component is (very usefully and consistently) parameter-centric, it is a pity that OnCheckClick requires work to connect it equally easily with the parameter(s) being enabled and disabled.
The checkbox shouldn't be treated as a parameter. This is similar to a node in a TParamTreeview where the node shouldn't be treated as a parameter as well. The TParamCheckList is basically a TParamListBox with a checkbox, similar to a TCheckListBox is a TListBox with embedded checkboxes per item and the OnCheckClick is kept consistent with how a TCheckListBox is to a TListBox.