Bug: metadarkstyle revokes modal dialog's border style .... when a TTreeview shows hints

[klaus101]

Hi zamtmn, from another thread occasionally i found an ugly side effect definiively due to the dark theme:

• Have a modal dialog box = without icon (wanted here), but with the dialog's cancel button in the upper right corner of the dialog.
• Have a ShellTreeView or TreeView with some long item captions -> where Hints will appear (via ShowHint) when they are hovered.
  Works in light theme. With metadarkstyle files the following happens:
• when the mouse is hovering a long item so that the hint appears, the dialog box now will show up the application's icon.
  Should not be.

It appears to me that at hint painting some calls are triggered affecting the dialog style of the form.
Could you please try out the test project (you may want to replace the herein embedded metadarkstyle files by your own installation)?
_prob_ModalDialog_without_icon.zip

[zamtmn]

Yes, problem present((

[klaus101]

Thanks zamtmn!
For to exclude possible side effects of recent updates, i tried with a somehow older verison (around June 2023); but it's the same.

It does feel for me as if calls are triggered or allowed to pass that affect the form's style.
And this reminds me somehow on an older Lazarus issue about wrong pointer types shown here:
https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/19321

• with a hack shown here (i already have played with it, but for light theme it's no longer needed):

procedure TForm2.FormActivate(Sender: TObject);
begin
   SetClassLongPtr( Form2.WindowHandle, GCLP_HICON, 0);
end;

• and thoughts around:
  "All these need to have SetClassLong replaced with SetClassLongPtr
  so they won't fail on win 64bit: .....
  And SetClassLong isn't the only one that needs replacing.
  Just in the post above i see GetClassLong that needs updating too.
  Someone should go in and adjust all these calls *Long to new *LongPtr, and while there also check others that have been changed in 64bit windows."

Remark: the testcase given at the end of the report behaves correctly for me with newer Lazarus version and light theme.
Do you see any possible dependency, or any chance to track it down?

[zamtmn]

I don't have any thoughts on how to fix it yet((

[klaus101]

Same here, unfortunately ..
Couldn't see any suspicious 'stay-behinds' regarding the fix the gitlab issue mentioned above points to:
https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/19439
(about Get/SetClassLongPtr, Get/SetWindowLongPtr). Seems such adaptions had been already done.

Did some theories, researches and experiments, but no clues on my side either.
What i can say: as expected, it's not specific for the treeview (same with virtualstringtree, listview and probably others).
And, i tried it with older dark mode files as derived from doublecommander in the early days of the laz. discussions about this topic (approx. begin 2023). They behave just the same. (test attached)

Why the painting of a hint manipulates the parent dialog form's style so that an icon does appear?
Hm ... maybe someone has a good idea ....
_prob_ModalDialog_without_icon__dc_version.zip

[klaus101]

I have news about this matters (be happy, i would think a fix won't be on the metadarkstyle side):
https://forum.lazarus.freepascal.org/index.php/topic,68900.0.html
Unfortunately there were none feedbacks so far.

[klaus101]

Fix/workaround committed on the Lazarus side :-) - details here:
https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/41189

[klaus101]

So closing