Closed klaus101 closed 9 months ago
Thanks @zamtmn for the merge, so closing ...
Late-wise i recognized that possibly the part "if Msg = WM_ERASEBKGND then" gots redundant, as "TWin32WSStatusBar.DoUpdate(StatusBar);" will be triggered twice needlessly. I'm not really sure yet if this part simply might be removed. The " if ((Msg = WM_PAINT) Or (Msg = WM_ERASEBKGND) ) then " part should do the job fully.
Not quite sure yet though if the results (from single or doubled call of !DoUpdate!) are really the same. Unfortunately there is no "flicker-measure" tool to verify ...
@zamtmn, if you should have a minute free, maybe you could tell me your opinion.
Yes, i take the previous thread about statusbar flicker (#20) into account (which covers a different use case).
Besides: if somebody should ask why i not simply do a FillRect, using the disired color, for WM_ERASEBKGND but do the full paining here: other it won't work. At restoring the app from the task bar, the contents will appear to be emptied. It needs a full repaint here.
Unfortunately, my knowledge is not enough to quickly tell what the problem is, and there is no time to experiment now. I can only confirm that there is a problem and it seems to me that the latest patch has not reduced it. I see a complete flicker of the entire window, not just the status bar
(Thanks for response!) Oh, that astonishs me really, as for me with the latest fix (which covers a partial issue that had not been covered yet), nearly none (white) flicker appears now.
So my last purely theoretical question had only been about a potential small code cleanup (removal of the WM_ERASEBKGND block as now redundant here), where I’m not fully sure, But I feel no more problem.
Though i’d need to add that it may happen that I have some few additional WMEraseBkgnd interceptions on app- resp. component level for certain cases. At the end it’s working really really fine here.
So I’m a bit astonished … if somewhere some small demo project should come up for to cross-check, I’d be happy to look into.
I'm just looking at Lazarus with the CustomDark theme. When hiding/showing, the white flicker is very noticeable
Ok, actually I’ve not yet installed the metadarkstyle within the IDE, hm, maybe I should do, but actually I’m focused onto the programs. But I’d guess that probably the IDE’s code might be not fully optimized for to take best benefit of the dark style. What I mean: sometimes within own programs I see it’s better to do some special modifications at WMEraseBkgnd on app level, typically eg. for Panels, Splitter, Entryfields especially if they are long; Listview could be a very specifc thing especially if doublebuffer is used. Will require individual analysis of a special reason and care for it anyway. I’d never vote for to squeeze too much of it within the metadarkstyle files – this can easily become counterproductive. My overall experience with the recent metadarkstyle is: rarely flicker, and if any, there are means on application level too.
The latest statusbar fix solves the “restore from taskbar” issue in four of my program. I would be wondering what’s special wiith the statusbar in the Lazarus IDE.
Working with my apps I sometimes noticed a white flashing on the StatusBar when restoring the app from the taskbar (click on app's icon in the task bar, statusbar flickers a bit when restoring). // Win 10 Do you see such too? I add a short clip fpr to show.
https://github.com/zamtmn/metadarkstyle/assets/31130146/39b29b61-2504-4f2f-9bab-87ecfd5cde99
No big deal. but not very nice either ... After some attempts I found a little fix (that might sound a bit strange, i’m aware): uwin32widgetsetdark.pas
It’s only for to achieve that the painting is processed a bit earlier here ... Alternatively it's possible of course not to exit at WM_ERASEBKGND but to process WM_PAINT subsequently (basically the same, but looks more native):
Btw I’d had a similar thing with the listview as well as it's column header. Maybe later here, don't know.
By that occasion I noticed that the color of the StatusBar had changed since my some earlier workings with the dark theme. That’s because it refers to COLOR_MENUBAR which’s content obviously did change some time ago. So ii did set it back:
Looks better for me. What do you think?