VT Header draws smudged (see screenshot)

[vincentparrett]

From [email protected] on December 19, 2011 22:14:37

I recall VT's painting to be quite smooth when I used it in D7 (with Mike's releases). Now, the painting, when dragging a column, seems to be really lagging behind, and sometimes when you click on the column header and drag really quickly, you get a smudge (see screenshot). I disabled theme awareness; same problem (speaking of theme awareness, even when it was off, the XP mode was a really nice feature, now gone).

Attachment: vt2.png

Original issue: http://code.google.com/p/virtual-treeview/issues/detail?id=248

[vincentparrett]

From [email protected] on December 23, 2014 14:02:39

Is the problem still there in V5.5.1?

[vincentparrett]

From [email protected] on January 06, 2015 18:48:51

This fail draw occurs on 5.52 too. When you try to change column order, and mantains cursor in vertical header range the control draws a piece in selececter column color. any solution at this moment?

[vincentparrett]

From [email protected] on January 08, 2015 10:44:58

I'm sorry, no solution from me. I personally never worked in this part of the code so far.

[vincentparrett]

From [email protected] on January 08, 2015 16:23:02

Thanks any way, last thing, do you have any clue where can I start to find this bug?, or can you contact the person that work in this behavior.

[vincentparrett]

From [email protected] on January 09, 2015 04:02:38

Let me check if this is still the case - will get back to you ASAP.

[vincentparrett]

From [email protected] on January 14, 2015 17:09:41

Ok, I found a "more or less" solution.
The problem is first capture of the dragging button, in the TVTHeader.HandleHeaderMouseMove make the correct operation, changing DownIndex to NoColumn, and redrawing the header with an Invalidate but it need a direct repaint, not an invalidate, so, the code captures the header button before repaint the button in release state (the WMessage is processed later).

The solution is in TVTHeader.HandleHeaderMouseMove line 12572 in v5.52, you need to add an treview.update after invalidate, then process pending messages before call preparedrag and capture the blue button for background.

Change this ---->

if I > NoColumn then
Invalidate(FColumns[I]);

with this ---->

if I > NoColumn then begin
Invalidate(FColumns[I]);
Treeview.Update;
end;

The problem with a lagging draw is not corrected, but that is another problem, slow folow the mouse cursor and a lor of blinking, and seems that text move into dragable button. Now beautiful to see.

[vincentparrett]

From [email protected] on January 15, 2015 09:40:55

This code (draw on drag, this is an incredible control anyway) seems to be very buggy. Another thing with simply solution is when you drag one column not show dragcursor, to solve this, insert Windows.SetCursor(Screen.Cursors[self.DragCursor]); in first line after begin in DoHeaderDragging method.

[RicardoBer]

At this moment this problem continues, do anyone know something more about this?

[joachimmarder]

Do you have simple repro steps for this issue with one of the sample projects?

[RicardoBer]

Yes, it fails always when move any hader tab. For example in advanced demo, four button.

Try dragging over header.

I remove that blue piece adding and update on HandleHeaderMouseMove method, but this ugly behavior continues in latest version, any way the drag operation shows lagging and blinking.
The control show good, but not in this case.

[RicardoBer]

There are another problem with circled arrow icons that paint on the sides of header buttons, they are cropped, some times it's now drawed other ones remain drawed, buf.

[sanjayssk]

I can't seem to reproduce this problem on my Win 10 and Win 7. The screenshot above where the "Column3" is smudged--was it a VM being used?

[RicardoBer]

The problem was reproduced on windows 7 ultimate clean installation, not in VM (yes I test on a VM windows 8 and one VM windows XP (I know, XP...). And fail in all of them, persistent error. I compile it with delphi XE7 and XE3.

Only pick column and move it from left to right and viceversa some times and problem arise. If you need that I make more test, please tellme.

Upper capture was with unmodified demo app.

Another one from a vcl styles app.

[sanjayssk]

Please test with the latest commit and confirm that the problem is solved.

[RicardoBer]

Worst,

I download latest version from github (thursday 4/08/2016) and the icons seems to be more affected, this time some icons or pices of them appear in others colums headers (look at left of "Localidad").

[sanjayssk]

I just committed a fix for this header smudge problem. Please test it and let me know whether it works better.

Thanks.

[RicardoBer]

I download latest version today, and sorry, but worst.

Blinking is higher and many times background is drawed over drag object. In the image the dragged object is under col 1 header. This behavior doesn't occur in previous version.

I only can say thanks by this control and I hope you forgive me, but I think all this artifacts are all in one point, the code that draws the dragging object and restore background is buggy.

Some comments above I talk about add an update aften an invalidate, I know, I update entire treview, so I am shooting a fly with a canon, but the problem goes better. I think thak mouse move events capture background before invalidate in mesage queue is procesed, so, background is corrupted.

[sanjayssk]

I can't see any difference in blinking from previous to this one. The blinking occurs only when the drag goes over a new column. That is same as before. Are you using a VM? I'm not using a VM.

many times background is drawed over drag object

Whatever I do, I can't recreate that problem. Can you give me steps to recreate the problem shown in the screenshot? Also tell whether you are using a VM.

Thanks.

[RicardoBer]

Hello, no I'm using an q9550 with ati 6870, Windows 7 64bits, no vm. I tested today in other two pc with windows 7 and one more with windows 8, same problem in all of them. I only catch a column header and displace to the left over other columns. In deed i can only see that works well on windows XP but I read the code and in xp use other mechanism.

Tomorrow I'm goint to prepare a windows 10 machine ( no vm) and test too, i'll send a capture

[sanjayssk]

OK. I got it now why I'm not seeing the same problems as you. All this time, I have been testing under Windows 10, assuming that it's same underneath as Windows 7, at least for win32 apps. In Windows 10, the fix works quite well and I can't duplicate that problem at all. But after your message, I just tested on an old Windows 7 laptop, and I can duplicate the problem of drag image going under immediately.

So it seems, Microsoft seems to have done some work under the hood in Windows 10. It's different after all, even for Win32.

Thanks.

[RicardoBer]

Yes, it behavior it's different depending on windows version. In windows 10 less lagging (many anyway), don't paint behind header, but cut position indicators.

[sanjayssk]

Well, I have made some major changes to fix this issue. I tested this time on Windows 7 too. I no longer see the blue rectangles, delay and partial drop marks being painted. Please use the latest commit to test the fix and let me know if you still see any problems.

Thanks.

[sanjayssk]

I'm closing this issue. If you happen to still find any related problem, please open it again. Thanks.

[RicardoBer]

I can’t test it, latest build is not installable on Delphi XE7. I open Issue #655

[joachimmarder]

Sorry, #655 is fixed now.

[RicardoBer]

Sorry but

---

El software de antivirus Avast ha analizado este correo electrónico en busca de virus.
https://www.avast.com/antivirus

[RicardoBer]

Sorry but the problem continues although only occurs when move the header for some time, it is near to work indeed.

This capture is from just now, with the latest build.

It is much more difficult to reproduce the error, but it is possible now in windows 7.

The position icon is cutoff.

[sanjayssk]

Thank you for testing. Can you explain what you mean by position icon is cutoff? If you mean the DropMark on the left, it was a bug. Dropmark should not appear if the column is not going to change position. See issue #643. Other than that, please give more details on what problem you see. Thanks.

[RicardoBer]

No, thanks to you, awesome work,

Ok, In that capture I move the Column 3 between "column" and "Column1" if you look on top of "C" letter of Column 1 you can see a piece of the Dropmark.

[sanjayssk]

I see now. I saw the problem in painting C but didn't realize it was a drop
mark that was causing it. Thanks for catching that.

On Thu, Sep 15, 2016 at 7:50 AM, RicardoBer [email protected]
wrote:

No, thanks to you, awesome work,

Ok, In that capture I move the Column 3 between "column" and "Column1" if
you look on top of "C" letter of Column 1 you can see a piece of the
Dropmark.

—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
#248 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ATX-xmYai6nENJIz0WoKRZnpFg79lsKnks5qqKtggaJpZM4DVOXT
.

[kong-en-ge]

#248 (comment)

There are another problem with circled arrow icons that paint on the sides of header buttons, they are cropped, some times it's now drawed other ones remain drawed, buf.

This issue seems to have a simple solution after hours of investigations.
In TVTDragImage.DragTo add the bold line:

// If moved more than image size then just restore old screen and blit image to new position.
BitBlt(ScreenDC, FImagePosition.X, FImagePosition.Y, FBackImage.Width, FBackImage.Height,
FBackImage.Canvas.Handle, 0, 0, SRCCOPY);

GetPixel(ScreenDC, FImagePosition.X, FImagePosition.Y);
if ForceRepaint then
UpdateWindow(FOwner.Handle);

This looks to be an enforcement of correct access sequence to ScreenDC inside the WinAPI.
First we restore backup image, then update window to reflect column header changes (this part often skips and causes bad circle icon traces), and then take the updated part to the back buffer.
Any access to ScreenDC content looks to be such an enforcement, and I chose GetPixel since it doesn't change the device state in any way.

[joachimmarder]

Thanks, I added this line (without testing) to the master branch.