http://bugs.winehq.org/show_bug.cgi?id=59034
Bug ID: 59034 Summary: Client area of CLM Explorer main window is rendered completely black on startup Product: Wine Version: 10.19 Hardware: x86-64 URL: https://www.tmsware.com/SetupCLME.exe OS: Linux Status: NEW Keywords: download, regression Severity: normal Priority: P2 Component: win32u Assignee: wine-bugs@list.winehq.org Reporter: arethusa26@gmail.com CC: pgofman@codeweavers.com Regression SHA1: 8d7de32cd646f3d1f118836e643e6146c9837278 Distribution: Fedora
Created attachment 79782 --> http://bugs.winehq.org/attachment.cgi?id=79782 CLM Explorer debug output
With wine-10.19, after starting CLM Explorer, the client area of the main window appears to be completely black. To work around this issue, I had to explicitly minimize the window and then restore it. This problem did not occur with wine-10.10.
Regression testing identified the following commit:
8d7de32cd646f3d1f118836e643e6146c9837278 is the first bad commit commit 8d7de32cd646f3d1f118836e643e6146c9837278 (HEAD) Author: Paul Gofman pgofman@codeweavers.com Date: Tue Jun 24 20:29:28 2025 -0600
win32u: Respect STARTF_USESHOWWINDOW in show_window().
I also observed an issue that may be related. If I try to take a screenshot of the main window with incorrect rendering by requesting the Spectacle tool to capture the active window, I get the following error:
An error occurred while taking a screenshot. KWin screenshot request failed: Invalid window requested Potentially relevant information: - Method: CaptureActiveWindow - Method specific arguments: QMap(("include-decoration", QVariant(bool, true))("include-shadow", QVariant(bool, true))("native-resolution", QVariant(bool, true)))
Also, when running CLM Explorer with a virtual desktop enabled, I notice that the main window starts in a minimized state. I have to restore it in the virtual desktop to interact with it.
http://bugs.winehq.org/show_bug.cgi?id=59034
--- Comment #1 from Andrew Nguyen arethusa26@gmail.com --- Created attachment 79783 --> http://bugs.winehq.org/attachment.cgi?id=79783 Incorrect rendering of CLM Explorer main window
http://bugs.winehq.org/show_bug.cgi?id=59034
--- Comment #2 from Andrew Nguyen arethusa26@gmail.com --- Created attachment 79784 --> http://bugs.winehq.org/attachment.cgi?id=79784 Correct rendering of CLM Explorer main window
http://bugs.winehq.org/show_bug.cgi?id=59034
--- Comment #3 from Andrew Nguyen arethusa26@gmail.com --- Created attachment 79785 --> http://bugs.winehq.org/attachment.cgi?id=79785 Minimized CLM Explorer main window in virtual desktop
http://bugs.winehq.org/show_bug.cgi?id=59034
--- Comment #4 from Paul Gofman pgofman@codeweavers.com --- Could you please describe exact way how do you launch the app to get the black screen? I briefly tried to reproduce, I saw the black screen when started the game after installing with the linked setup and choosing to start the app from the installer. But then, starting CLMLaunch.exe from command line or systray (if the icon is left after closing the window before) doesn't reproduce the issue here (it is also possible that the app updated itself). Is there a way to reproduce on installed game, or the issue only happens when run from installer?
http://bugs.winehq.org/show_bug.cgi?id=59034
--- Comment #5 from Andrew Nguyen arethusa26@gmail.com --- In my testing, I have always launched CLM Explorer either from the installer after it completes or by starting it from the command line with CLMLaunch.exe with no Wine processes initially running (so after I ran "wineserver -k" and never from the systray icon). I am able to reliably reproduce the issue with the main window client area this way.
However, I do see that when I enable virtual desktop, maximize the main window, and then close the window, the main window seems to remember the maximized state on subsequent launches. If I terminate all Wine processes and disable virtual desktop, relaunching CLM Explorer does seem to make the main window maximized with a rendered client area. The first launch shows only the area with the size that it had in the virtual desktop, and the subsequent launch shows correct rendering for the full size of the maximized window.
http://bugs.winehq.org/show_bug.cgi?id=59034
--- Comment #6 from Paul Gofman pgofman@codeweavers.com --- The (occasional, I saw that once but have troubles reproducing that here) black screen is most likely the consequences of the window being minimized upon first show (which is seen as such in virtual desktop mode). Without virtual desktop the window also gets minimized with the first ShowWindow but soon gets unminimized by window manager. That sometimes results in a faulty state due to some race (which is a bug on its own probably but not related here, the minimization on the first show window indeed ends up being wrong with the blamed commit). The game indeed remembers the last window state (position, minimized / maximized), so if it was minimized by user upon next run it will start minimized due to that reason, what happens in this case is unrelated to the blamed commit and this bug.
So the launcher starts the actual program with STARTUPINFO.dwFlags = STARTF_USESHOWWINDOW and STARTUPINFO.wShowWindow = SW_SHOWMINIMIZED (for some purpose totally unclear to me) and then the app itself shows it (MDI frame overlapped) window with ShowWindow( SW_NORMAL ). With the blamed commit that gets replaced with startupinfo's SW_SHOWMINIMIZED resulting in the observed behaviour. Turns out the window in question is created being owned by another WS_POPUP window and under these conditions showing of this window is not subject to fix up by startup info (nor resets 'firstness' of show window, showing eligible window after would catch starup info flag but that doesn't seem to happen with the app).
I sent a MR: https://gitlab.winehq.org/wine/wine/-/merge_requests/9578
http://bugs.winehq.org/show_bug.cgi?id=59034
--- Comment #7 from Andrew Nguyen arethusa26@gmail.com --- Thanks for looking into the issue and preparing a fix. I did some testing with your MR branch, and while I can confirm that the issue with the client area not rendering correctly no longer occurs for me, I now see a new issue that wasn't present before your fix.
Normally, if I try to close the main window, either by clicking on the close button on its title bar or selecting the File -> Exit menu option, I should see a modal message box asking "Do you want to Backup your datafile?" that takes focus and appears on top of the main window. The close button of the main window in the title bar also disappears, presumably to prevent it from being closed while the message box is displayed.
However, with your change, when I try to close the main window, it behaves as if the message box is being displayed, but there's no message box window that I can find, which makes proceeding with the close operation seemingly impossible.
Please let me know if I can provide any additional debug traces, as you reported difficulty with reproducing the original issue in your testing.
http://bugs.winehq.org/show_bug.cgi?id=59034
--- Comment #8 from Paul Gofman pgofman@codeweavers.com --- Thanks for checking this. I think I see what is the problem and it is still regressive with the blamed commit while is a completely different aspect / bug. With the initial issue fixed, the startup info show window flag is still not reset (as I mentioned before). Before the fix the flag was wrongly consumed on the initial window creation and thus wasn't affecting the exit dialog, while the fix still looks correct.
The exit dialog is just a MessageBox. After a lot of unit testing I figured that MessageBox behaviour is actually special WRT startupinfo flags. I updated the MR with more patches fixing these details: https://gitlab.winehq.org/wine/wine/-/merge_requests/9578
The updated MR should hopefully be fixing the exit dialog issue.
http://bugs.winehq.org/show_bug.cgi?id=59034
--- Comment #9 from Andrew Nguyen arethusa26@gmail.com --- With the latest changes to the MR, I can confirm that the CLM Explorer main window is rendered properly and the message box that appears on exit is also shown correctly. Thanks again for your help!