Address bar appearance with msstyles is messed up

[Olive6841]

Describe the bug
Sometime after the latest GitHub release 1.4.0, the appearance of the address bar with an msstyles has incorrect proportions and/or margins when not selected.

To Reproduce
Steps to reproduce the behavior:

1. Use the latest compile from source tree
2. Open Explorer++ with any custom msstyle

Expected behavior
A clear and concise description of what you expected to happen.
See right explorer window on the following screenshot

Screenshots
If applicable, add screenshots to help explain your problem.

Latest compile on the left vs the 1.4.0 release on the left

Version (please complete the following information):

• Explorer++ version 1.5.0.0 dev (64-bit build)
• OS: Windows 10 21H2

Additional context
Add any other context about the problem here.

[Olive6841]

Describe the bug Sometime after the latest GitHub release 1.4.0, the appearance of the address bar with an msstyles has incorrect proportions and/or margins when not selected.

To Reproduce Steps to reproduce the behavior:

1. Use the latest compile from source tree
2. Open Explorer++ with any custom msstyle

Expected behavior A clear and concise description of what you expected to happen. See right explorer window on the following screenshot

Screenshots If applicable, add screenshots to help explain your problem. Latest compile on the left vs the 1.4.0 release on the left

Version (please complete the following information):

• Explorer++ version 1.5.0.0 dev (64-bit build)
• OS: [e.g. Windows 10 21H2]

Additional context Add any other context about the problem here.

also visible in left of this screenshot you can see the menu bar in the latest 1.5.0.0 build is using a different msstyles class
not sure if this is intended or not

[derceg]

There are a few points to make here. The address bar theme is set to AddressComposited, since that looks better in dark mode. The menu bar is completely custom drawn to support dark mode as well. It's custom drawn even when dark mode isn't enabled, since switching between custom drawn/system drawn appears to be problematic and custom drawing the menu bar in both light mode and dark mode is better for consistency.

I don't know if it's possible to detect a custom theme like the one used here. Even if it is possible, there might not be much that could be reasonably done. The dark mode functionality implicitly assumes that the default theme will be light. If you're using a custom theme, that might not be true, which means that controls like the menu bar might look out of place in light mode.

Also, if you're using a custom theme, dark mode might not work properly either, since the dark mode visual styles might have been altered as well.

It's possible the only thing that could be done would be to disable the dark mode functionality altogether when using a custom theme, since a custom theme breaks the assumptions dark mode relies on and if the user has a custom theme it can be assumed that they will set up their own dark style theme if they want.

Since it might not be possible to detect a custom theme, disabling the dark mode functionality altogether would probably have to be done with a command line switch. That switch would prevent the user from switching between light mode/dark mode in the application and ensure that the menu bar is always system drawn. It could also stop the AddressComposited theme from being applied to the address bar.

Obviously, if you sometimes switch the application to dark mode, even with a custom theme, that solution isn't going to work. In that situation, I don't think there's anything else that could be done. Let me know what you think.

[Olive6841]

There are a few points to make here. The address bar theme is set to AddressComposited, since that looks better in dark mode. The menu bar is completely custom drawn to support dark mode as well. It's custom drawn even when dark mode isn't enabled, since switching between custom drawn/system drawn appears to be problematic and custom drawing the menu bar in both light mode and dark mode is better for consistency.

I don't know if it's possible to detect a custom theme like the one used here. Even if it is possible, there might not be much that could be reasonably done. The dark mode functionality implicitly assumes that the default theme will be light. If you're using a custom theme, that might not be true, which means that controls like the menu bar might look out of place in light mode.

Also, if you're using a custom theme, dark mode might not work properly either, since the dark mode visual styles might have been altered as well.

It's possible the only thing that could be done would be to disable the dark mode functionality altogether when using a custom theme, since a custom theme breaks the assumptions dark mode relies on and if the user has a custom theme it can be assumed that they will set up their own dark style theme if they want.

Since it might not be possible to detect a custom theme, disabling the dark mode functionality altogether would probably have to be done with a command line switch. That switch would prevent the user from switching between light mode/dark mode in the application and ensure that the menu bar is always system drawn. It could also stop the AddressComposited theme from being applied to the address bar.

Obviously, if you sometimes switch the application to dark mode, even with a custom theme, that solution isn't going to work. In that situation, I don't think there's anything else that could be done. Let me know what you think.

What about making it use the msstyles classes to the previous ones when using the explorer++ light mode?

[derceg]

In the default menu bar theme, the bar background is actually a bitmap. Due to technical limitations, you can't draw that bitmap in that empty part of the menu bar. That's important, since when the menu bar is custom drawn, the application has to draw the entire bar, not just the items. I believe the only way of filling the entire bar with the background bitmap would be to use undocumented functionality, which I'm wary of doing.

So, for the menu bar at least, I don't think there's any way of using the default background without disabling the dark mode functionality altogether.

For the address bar, the AddressComposited style could potentially be removed in light mode. The control doesn't properly repaint itself once the style has been removed, but it looks like it's possible to work around that. I might do that, since the AddressComposited style doesn't look right on Windows 7 and 8 anyway.