JAM-Software
Distorted shape when dragging the columns
Please respect our guidelines on the project homepage for submitting bugs. Please include your version of Virtual TreeView and Delphi, and attach a sample compiling project as ZIP to your report that allows to replicate the problem. If only small changes are required, a description is sufficient how a demo projects needs to be changed in order to replicate the bug. If you already have a solution, please supply a patch file.
This issue is occurring in the V8.0.3 release as well as the master repository code as at 2 October 2024 using Delphi 12.2.
The issue may be demonstrated using the "Minimal" or "Advanced (Tree in Grid Simulation)" demo applications by dragging the Tree column header with the mouse. The Drag image leaves artifacts during the dragging.
Additionally, when the DPI awareness is set to "DPI Unaware" on a Monitor with Scale greater than 100%, the drag image is positioned (offset) a far distance from the mouse. The further you move the mouse to the right or below the tree, the further away the drag image moves away from the mouse pointer.
HTH
A very similar issue was discussed intensively in 2016 in issue #248.
One possible solution could be implementing #806 and let Windows do the drawing.
I have now implemented column header drag and drop using Windows drag and drop, and it looks promising so far. I would appreciate it if several people could do some testing.
Thanks Joachim, I have done basic testing using the Advance.exe demo and my own applications.
Delphi 12.2, Dual Monitor, 3840x2160 @125% and 1920x1080 @100%
In both DPI Monitor V2 and DPI Unaware the Draw image is operating correctly, keeping with the mouse cursor and scaled appropriately when moved between screens. No more drag drawing artifacts.
However, when the header is dragged over the Delphi 12.2 IDE edit window:
- the application hangs if debugging the application in the IDE,
- or an AV error is encountered if running the application outside the debugger.
In both cases, the application must be terminated using end task. This does NOT occur for me dragging over the Delphi 11.3 IDE edit window, nor does it occur in other applications I have tried dragging over including One Note, MS Word, VS code, Edge and Windows Explorer. Additionally, I haven't had an opportunity yet to investigate whether any of the IDE extensions could be the culprit.
I will continue using and testing.
However, when the header is dragged over the Delphi 12.2 IDE edit window:
- the application hangs if debugging the application in the IDE,
I can confirm this. It is not a new behavior, it also occurs when using drag&drop with tree nodes. So it is a separate issue. I suppose it is a result of a bad drop target implementation in RAD Studio, especially since it does not occur with any other application. It shouldn't hurt too much in an average situation.
I know this issue is closed, but I wanted to let you know that this (temporarily) broke my app. I couldn't get the advanced demo to break, so I had to go searching for the commit that broke it (fcb170c).
I found that dragging and dropping columns no longer provided visual feedback but did work if you dropped the column in the main control or dragged over the main control. Because this changes the drag-and-drop behaviour, I needed to add the option toAcceptOLEDrop to all the tree views (I set them up in code for consistency in the app, not via the DFM).
I'm not asking for anything to be changed just putting a note here just in case this issue is reported by another user because they also found this behaviour.
Because this changes the drag-and-drop behaviour, I needed to add the option toAcceptOLEDrop to all the tree views
Thanks for submitting this finding. It makes sense, because header drag&drop is now based on Windows OLE drag&drop as well. That means we need to always register for OLE drop independent of the toAcceptOLEDrop flag.
@DGH2112 : Could you please check with the latest source code if this improves the situation for you?
Sorry @joachimmarder, bad week at work... I moved last weekend to V8.1.1 which I think was the latest at the time and with the tweak to my code to include the toAcceptOLEDrop, it all works as expected.
I can see that you've made another commit to change the behaviour, which I'll test tomorrow and let you know.
@joachimmarder, I can confirm that the commit fixes the issue without me needing to change my code. Thanks for this.