[TC 8.0b21 x64] Menubar background is not redrawn properly

[umbra]

In Aero, menubar background is not updated until TC's main window gets focus. This happens in many situations (system theme changes, resolution changes, theme changes in TC's Options dialog, ...) but the easiest way to see it is to start TC without license key.
Image: http://i1057.photobucket.com/albums/t399/uumbra8/TC/bugs/menufirststart.jpg

[sztihamer]

I can confirm this one too. It works with a fresh config file, and even after you close Total Commander and relaunch it. After you click the desired number that the application asks you to do it will revert back the way it should be. This bug can be easily reproduced on Total Commander 8.0β21 64bit. The 32bit version seems to be fine.

Operating system: Windows 7 Ultimate 64bit
Screenshot: http://i.imgur.com/ObWDI.png

[ghisler(Author)]

This is a known problem, but unfortunately I do not have any solution: Either you get this, or you get the menu item text with foreground colors, but you can't get both fixed at the same time.

The problem is that Windows doesn't send any notification to draw the menu bar itself, just the menu items.

[umbra]

Either you get this, or you get the menu item text with foreground colors, but you can't get both fixed at the same time.

I'm not sure what you mean. This bug was introduced in beta 19 and this is the only menu bar fix in that release:

05.02.12 Fixed: Moving cursor over main menu item while TC was in background -> other menu items would disappear (64)

Did this bugfix caused the current error? If yes, then I guess the current behavior is more acceptable.

[ghisler(Author)]

OK, let me explain: Originally Lazarus handles it like this: When it gets a message to redraw the first menu bar item, it repaints the entire menu bar background, and then sends a refresh message to itself to redraw all the menu items. This worked fine, but only when TC was in the foreground. With TC in the background, the text remained all black.

I tried to adapt it to draw the text grayed out in the background, but it didn't work (probably due to some repaint optimizations in Windows) with this two step redrawing solution. Therefore I was not painting the entire background of the menu when TC was not in the foreground.

But I think that I found a solution now for the next beta: When I get the command to redraw the first menu item, I draw just that, plus all the empty areas. This is quite complex because there can be many such parts (multi-line menu), but it seems to work.

[sztihamer]

Total Commander 8.0ß22 64bit fixes the problem. It works the way it should be. No more incorrectly drawn menu bar.

[ghisler(Author)]

Thanks! Can anyone else confirm it too, please?

[umbra]

Confirmed. Beta 22 works fine. Thanks.

[karlchen]

Hello, umbra.

Comparing your screenshot, menufirststart.jpg, and Loocas' screenshot, I think you both reported exactly the same error.

The difference is that you [1] saw it on an Aero theme, whereas Loocas [2] used a Classic theme.

The reported problem has been solved for both themes as confirmed by two or three users.

Yet, for Aero a new visual issue has been introduced. Why do you say so in the other thread (about classic theme) and not here in your own thread, too (about Aero theme)?

Kind regards,
Karl

[umbra]

Hi, karlchen. While the images look the same, it is a different error.

Loocas noticed, that the TC partially ignored color settings for menu (you can find them in the Windows Color and Appearance dialog). That error was visible in both Aero and Classic themes. And beta 22 is a second attempt to fix it (and so far the most successful).

The error reported in this topic has nothing to do with windows colors. The TC was simply not redrawing the whole menu, only a part of it - see ghisler's second post for a better explanation.

BTW, Loocas used Aero too - look at the window borders or title or other elements.

[karlchen]

Hello, umbra.

Oh, I see. With 3 threads holding screenshots where T.C. had painted inconsistent background colours in the menubar - depending on which Windows default colours had been changed away from their Microsoft default values - I had started to think that the underlying error had to be the same one in all 3 cases.

Cheers,
Karl

[ghisler(Author)]

Thanks, I will move this thread to "fixed bugs". Please report any other similar problems separately.