Window title not centered in programs which place buttons on to the title bar

[second2050]

Currently in windows of programs were buttons are placed on the title bar the window title is not centered. Is this intended or is this a bug?

Example 1 (Windows Live Photo Gallery 2012): Left: Window from Photo Gallery without "In-Title-Bar-Buttons". Right: Window from Photo Gallery with "In-Title-Bar-Buttons".

Example 2 (Windows Live Writer 2012):

[valinet]

Hi

Timing is excellent, it is just yesterday that I looked into this issue. The problem concerns applications that use a ribbon, like File Explorer, Paint, WordPad, as well as your examples. Specifically, these applications draw themselves the title, instead of DWM, based on the CONTENTALIGNMENT setting in the msstyles theme file that the system is using.

I have added relevant info in the README on how to patch the default aero.msstyles or any other style in order to center align that text, it is easier that way and it'd be way harder and prone to errors to do it by injecting via the daemon. Also, I have uploaded a pre-release binary that helps when using a custom theme (it forces DWM to choose the aero.msstyles code path, it is explained more thoughtfully in the README).

Here is an example of a ribbon window on my system with patched aero.msstyles:

Link to pre-release 1.1.0.0: https://github.com/valinet/WinCenterTitle/releases/tag/1.1.0.0

Also, please note that the new binary works, probably, only on Windows 10 Version 2004. The patched aero.msstyles should work with the old release as well (1.0.0.0), use that if 1.1.0.0 crashes.

[second2050]

Thanks for the fast reply but there is a problem regarding 1.1.0.0 on my side: • Pre-Release 1.1.0.0 seems to crash my dwm: When loading 1.1.0.0 my screen goes black for a second and the window titles are not centered even when updating the window. When loading 1.0.0.0 my screen does not go black and window titles are centered when updating the window by clicking it.

Regarding the msstyle edit: That worked beautifully but shouldn't that also require a uxtheme patch? If yes, then you should add that to the readme.

[valinet]

That worked beautifully but shouldn't that also require a uxtheme patch? If yes, then you should add that to the readme.

Yes, naturally, I use UltraUXThemePatcher, but any patcher should work, I forgot about that. Theoretically, one could inject all offending applications and hook the Win32 function that is responsible for reporting the CONTENTALIGNMENT property (I don't think it is GetSystemMetrics, although I am not very familiar) and alter it accordingly, although, yeah, that will take a lot more time to implement and it is pretty cumbersome to inject all applications or maintain a whitelist. This solution is the quickest and works 100%, yet indeed, it requires theme signing to be off.

Pre-Release 1.1.0.0 seems to crash my dwm:

That's expected, I guess. The new binary edits a value in DWM so that when you use a custom msstyles, title bars are drawn white when you have the 'Show accent color on the following surfaces: Title bars and window borders' option in Personalization\Colors in Settings disabled. The location of that flag is hardcoded in the binary to the version of uDWM.dll on my system, and, as I said, I am using Windows 10 Version 2004 at the moment. In the future, I should get the address of the variable from the symbol file, dynamically, at run time, but again, that's a lot of work and not so much in return, when it takes 5 minutes to open uDWM.dll in IDA, ghidra or something similar and look for the offsets:

• First, search for "g_pdmInstance" (0xE6D88 is address of it on my uDWM.dll, base at 0x0). This is a global variable that holds a pointer to a CDesktopManager* instance. That pretty much means that the class is in fact a singleton. You can determine this by examining the exported function DwmClientStartup, which looks like a staring point of the DLL. That function, in turn, calls CreateDesktopManager, which in turn calls the constructor for CDesktopManager. That constructor returns a pointer to the allocated class, which after a call to InitializeCDesktopManager, is stored in g_pdmInstance before CreateDesktopManager ends.
• That's half of the problem. Now, what to do with that? If you search for "aero.msstyles", you will find it referenced in CDesktopManager::LoadTheme. The string is compared with another string variable (which actually holds the name of the current theme in use). The strings are compared with wcscmp: a return value of 0 means the strings are the same, while a value that is not 0 means that the two are different. The value is reduced to either 0, or 1, flipped and is stored at rdi + 0x19. On closer inspection, rdi is set to rcx at the beginning of the function. According to the x64 calling convention, on Windows, rcx is the first argument of the function, and since we are in a C++ class (an object-oriented "object"), the first argument is always "this", which is a pointer to an object of type CDesktopManager.
• So, if CDesktopManager is indeed singleton, since we have the address of its instance, in g_pdmInstance, and we also know the offset of where the information about whether we use aero.msstyles or not is stored, at 0x19 from the beginning of a CDesktopManager, we can try to set the location *g_pdmInstance + 0x19 ourselves. That is indeed what the small added snippet in 1.1.0.0 does, and sure enough, the changes can be observed immediately, it works (and does not crash DWM), confirming our assumptions.

That's the principle of finding those values, doing that in code will take way more time than looking manually on the file. What probably differs in your case is the location of g_pdmInstance in memory of your uDWm.dll.

I should probably add this explanation to the README as well.

[valinet]

I have implemented logic that automatically downloads PDB files for dwm (uDWM.exe) and retrieves the addresses of necessary symbols to patch for “aero.msstyles” code path. This way, you will keep white title bars if using a custom theme, instead of colored ones, as is default. So, besides using the latest version, to get centered title bars in ribbon applications as well, one is required to disable theme signing using a uxtheme patcher, create a modified aero.msstyles with centered CONTENTALIGNMENT for window caption and maxcaption, and apply that. That’s the procedure for now. I consider this issue to be dealt with, I have added the necessary mentions to the README file as well.

You can binaries for the latest version (1.1.0.0) from Releases.

Thanks for the information.