Q: known ways around to suppress black regions when maximizing window?

[d7_2_laz]

Noticed that from time to time and was wondering if there are already known ways for improvement.
Windows x64; not specific to 2.2 (occurs with 2.0.12 too), but i did never see it with Delphi.

Have a form with a treeview (inside a TPanel, or a TSCrollBox, or standalone without container).
When doubleclicking on the caption bar, so maximizing the window, for a noticeable period of time a black region inside the maximized window can be seen.
See the screenshot catching the moment when the wm_size message is arriving.
Of course it's not functionally relevant. But it's not nice either and i would be interested to know if it could be improved.

Tried typical candidates for improvement (DoubleBuffer; intercepting the WM_ERASEBKGND message; setting Params.WindowClass.hbrBackground := COLOR_BTNFACE + 1); playing with ParentBackground et.al.,  but no change.
I'm wondering where the black erasure color at the end comes from and why it's so reluctant to change it.
A test project is attached.

My question is: can anybody confirm the observation? And does anybody have an explanation or knows a workaround so that at least the background erasure doesn't use a black brush color but a white color?

Remark: as told, it was not with Delphi apps.
Second: the only way to change it i saw was to set params.exstyle to WS_EX_TRANSPARENT, but that leads to other trouble, starting from disappearing scrollbars etc. (not a desired approach)

[440bx]

I can _partially_ answer your question.  You can set the background of a window to just about any color a brush can be using SetClassLong (or SetClassLongPtr)

The call is like this:

Code: Pascal  [Select][+][-]

1. SetClassLong(
2.   hWnd,  { the window (and class) whose background you want to change }
3.   nIndex, { set to GCL_HBRBACKGROUND to select the background color }
4.   dwNewLong { the colored brush handle - best is to obtain it using GetSysColorBrush }
5. );

I'm sure it's easy to get the hWnd of a form but, since I don't know/remember how, I'll let someone else answer that part.

HTH.

[PascalDragon]

I'm sure it's easy to get the hWnd of a form but, since I don't know/remember how, I'll let someone else answer that part.

I think the problem is more that something forgot to trigger a correct redraw, cause if you look at the screenshot you can see that the scrollbar stretches till the bottom with a horizontal one there, but there is also a ghost scrollbar around the middle (which was probably the original size).

[440bx]

I think the problem is more that something forgot to trigger a correct redraw, cause if you look at the screenshot you can see that the scrollbar stretches till the bottom with a horizontal one there, but there is also a ghost scrollbar around the middle (which was probably the original size).

I strongly suspect you're right.  I figured I'd tell him how the background is controlled using the API. 

I usually don't respond to questions that involve TWhatevers because there is often a lot more going on than is taken care of with an API call.

[d7_2_laz]

Many thanks you both for your replies!

On the ghosted scrollbars, it's probably due to the embedded control (the Treeview).
For to avoid such complication, i renewed my test simply using a form and a panel..
Te principle (the black region) is the same, see screenshot attached, forced when reaching wm_size (for form or panel).. -
Off course without the embedded control in this simple scenario all runs fast and is hardly to recognize).

On the API,  i was wondering if it would have a different effect than setting Params.WindowClass.hbrBackground to another color. I did try it as (in FormCreate):

Code: Pascal  [Select][+][-]

1.    SetClassLong(handle, GCL_HBRBACKGROUND, GetSysColorBrush(COLOR_WINDOW) );
2.    //SetClassLong(PanelLeft.handle, GCL_HBRBACKGROUND, GetSysColorBrush(COLOR_BACKGROUND) );
3.    SetClassLong(PanelLeft.handle, GCL_HBRBACKGROUND, GetSysColorBrush(COLOR_WINDOW) );
4.  

Changing COLOR_WINDOW to other index values didn't make any difference here, so at least in this notation it appears to me it doesn't come into effect

[d7_2_laz]

The way it seems to work, is:
in FormCreate, applying SetClassLongPtrW either to the form's handle or panel handle or both:

Code: Pascal  [Select][+][-]

1. SetClassLongPtrW(PanelLeft.handle, GCL_HBRBACKGROUND, 6);     // 5: lightgray   6: white

Not fully sure yet why it accepts this constant number(s) as argument.  But anyhow it has the desired effect, the annoying black artefacts at resize are disappearing.

[d7_2_laz]

Notice: after a long time of usage i encountered a side effect; see:
https://forum.lazarus.freepascal.org/index.php/topic,59664.0.html

Maybe some alternative solution does exist?