Forum > LCL
[FIXED] Win. dark themes, modal dialog box's icon when control shows hints
d7_2_laz:
This is a relict of:
https://forum.lazarus.freepascal.org/index.php/topic,68765.0.html
Windows 64 bits, Laz. 3.6.:
- Have a modal dialog box = without icon (wanted here), but preserving the dialog's cancel button in the upper right corner of the dialog.
- Have a ShellTreeView or TreeView or virtualstringtree or listview or ... with some long item captions -> where Hints will appear (via ShowHint) when they are hovered.
- This works fine in light theme. With metadarkstyle files the following does happen:
when the mouse is hovering a long item so that the hint appears, the dialog box now will show up the application's icon.
This should not be.
I checked against these gitlab issues about required Win64 changes ("hopeing" somehow that the theme code is not up-to-date):
https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/19321
https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/19439
dealing with (Get/Set)ClassLong vs. (Get/Set)ClassLongPtr. But nothing suspicious could be found.
- I tried it now with older dark mode files as derived from doublecommander in the early days of the discussions about windows dark mode in this forum (approx. begin 2023).
They behave just the same (-> test project attached).
So it's not mainly related to metadarkstyle's files itself.
==> How might it come that the painting of a hint manipulates the parent's dialog form's style so that an icon does appear?
Incorrect subclassing of form's window procedures, deficits in parameter passing so that return values are falsified or unintendedly defaults returned?
Any idea from specialists would be welcome ...
d7_2_laz:
I noticed that when the hint is shown, "TCustomForm.IconChanged" is called (customform.inc).
So i inspected the call stack (see image), going, from that, back until i found: THintWindow.CalcHintRect (hintwindow.inc).
This CalcHintRect triggers some "if HandleNeeded", "CreateHandle", "CreateWnd" etc.pp.
until i could locate what probably causes the icon's revival (with impact not on the light theme, but, yes, on the dark theme):
--- Code: Pascal [+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i < x.length; i++) { x[i].style.maxHeight='none'; x[i].style.height = Math.min(x[i].clientHeight+15,306)+'px'; x[i].style.resize = "vertical";}};} ---procedure TCustomForm.CreateWnd;begin ............. // update icon Perform(CM_ICONCHANGED, 0, 0); // <<<<============================= here ............. end;
If i look - after the hint is shown - onto the form directly before and after execution of this line, in fact
it is responsible for to make the icon to appear.
"cm_iconchanged" sounds harmless (just as a notification that something happened), but in fact it forces here that it happenns.
Unclear, why only for the dark theme.
But the question is, is it possible and how to make it more robust .... ?
d7_2_laz:
Yes it does, resp. is expected to do (to be more than a pure information):
https://lazarus-ccr.sourceforge.io/docs/lcl/forms/tcustomform.createwnd.html
--- Quote ---The CM_ICONCHANGED control message is performed to (re-)create handles for menu glyphs, and to post the changes to the widgetset class.
--- End quote ---
Unfortunately i see nowhere within the Lazarus code, where - except doing Perform(CM_ICONCHANGED, 0, 0) - the message CM_ICONCHANGED itself is processed .......
Correction: The latter is wrong of course. The connector is here:
--- Code: Pascal [+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i < x.length; i++) { x[i].style.maxHeight='none'; x[i].style.height = Math.min(x[i].clientHeight+15,306)+'px'; x[i].style.resize = "vertical";}};} --- procedure CMIconChanged(var Message: TLMessage); message CM_ICONCHANGED;Sorry for that!
d7_2_laz:
Nevertheless. The following idea:
In my test scenario (project files attached above) i have the line in question executed 3 times:
1. for the main form --> property Name is "Form1"
2. for the opened modal dialog --> property Name is "DlgTest"
3. when the hint for the embedded treeview is shown --> property Name here is "" resp. nil
So, now, why not benefit from this ?? (customform.inc)
--- Code: Pascal [+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i < x.length; i++) { x[i].style.maxHeight='none'; x[i].style.height = Math.min(x[i].clientHeight+15,306)+'px'; x[i].style.resize = "vertical";}};} --- // update icon if Name <> '' then // Exclude unintended icon handling Perform(CM_ICONCHANGED, 0, 0);
Works!
I recompiled my main app, having different scenarios (simple modal dialogs without icon; more complex modal dialogs with intendedly having an own icon). Works!
Retested with light theme (regression?); works.
Retested with the metadarkstyle files; works.
Does it help for hints on other embedded controls too? Chcked for VirtualTreeView -> yes, ok
(btw. my original pointer to the listview was by mistake. Hints herein don't span outside the control or the dialog box or the main form)
-> Are there any opinions about?
d7_2_laz:
In case anyone is wondering what I'm even talking about, I've attached a short video.
Navigation
[0] Message Index
[#] Next page