TRzCustomTabControl's paint cycle

[dave_lifeway]

Hi Ray!

When the mouse is within the tab control's bounds it turns out that a full paint cycle (i.e. ClipRect is the full client rect) is being called endlessly, even if the mouse isn't over any tabs. While that alone isn't great, it gets worse, because if the card isn't being shown, then the tab control's parent is being painted endlessly, too.

This stems from the call to StopHotTracking being called every message cycle from the MouseMove handler, and that routine calling InvalidateRect on the full client whether there's any real need to redraw anything or not.

Is there a change I can make somewhere to avoid this continuous painting?

Thanks,
Dave

[Raize Support]

Hi Dave,

Do you have an example project that illustrates the problem you are running into? If so, please send the source code to support@raize.com and I'll take a look.

I checked the code and created a test project, and the StopHotTracking method does get called on a MouseMove, but this method and the InvalidateRect call does not get called if the mouse doesn't move. Therefore, I'm not quite sure what you mean by "painted endlessly". Also, the rectangle that is invalidated is the rectangle that contains the tabs. I do not see the parent painting endlessly as you describe.

Ray

[dave_lifeway]

zip file sent.

So a couple of things ... the continuous .MouseMove messages aren't happening in this sample, so I'll chalk that up to something amiss in our app, and look into it. The parent is definitely being called to paint on every mousemove, as you'll see in the sample.

The full repaint I'm seeing comes from .StopHotTracking, where IndexRect := GetIndexRect ends up being the entire bounds of the control. Maybe that has to do with ShowCard := False?

Thanks,
Dave

[Raize Support]

Thanks for the test project. I'll take a look.

As for the IndexRect size, that will take up the entire control size when the ShowCard property is False, because in this case, the entire rectangle is used to display the tabs. What size is your control in this situation? Do you have really large tabs?

Ray

[dave_lifeway]

Normal size tabs (rounded), but the control can potentially be fairly wide. So every trip to the menu bar or toolbar is likely to trigger a paint cycle (or a few) of the tabs as well as the containing control. In my case the tabs are properly clipped out by the parent, so this isn't the zombie apocalypse or anything. But in principle, it'd be nice if the tabs didn't invoke the parent's paint cycle unless there really was a visual change.

[Raize Support]

Hi Dave,

Thanks for sending the test project. In the sample project, the FormPaint event handler does get called when you move the mouse in the empty area of the tab control. However, the painting does indeed stop when you stop the mouse. More importantly, the FormPaint event does not fire once you move the mouse over a tab and the tab becomes hot. After that, the form paint does not fire.

We'll take a closer look to see if we can stop the initial paint calls. One thing that is subtle in all this is that the region that we are talking about is a transparent region of the control. That is, this area will display the parent's (in this case the form's) background through the control. I'll have to take a closer look at the code to see if this is affecting the paint calls.

Ray