[Bug 59478] New: SolidWorks 2025: owner-drawn buttons inside large (10000x10000) child window receive WM_LBUTTONDOWN but BN_CLICKED is never sent
http://bugs.winehq.org/show_bug.cgi?id=59478 Bug ID: 59478 Summary: SolidWorks 2025: owner-drawn buttons inside large (10000x10000) child window receive WM_LBUTTONDOWN but BN_CLICKED is never sent Product: Wine Version: 11.0 Hardware: arm OS: MacOS Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs@list.winehq.org Reporter: junkwalkers@gmail.com Created attachment 80468 --> http://bugs.winehq.org/attachment.cgi?id=80468 Window hierarchy dump from inspector tool SolidWorks 2025 Education Edition hosts PropertyManager controls inside a child window titled "Dve sheet" sized 10000x10000 pixels. Owner-drawn buttons (BS_OWNERDRAW, style 0x5001000B) inside this window visually depress when clicked (WM_LBUTTONDOWN is delivered) but the BN_CLICKED notification (WM_COMMAND) is never sent to the parent window on mouse release. Steps to reproduce: 1. Install SolidWorks 2025 in a clean wineprefix 2. Open a part and enter sketch edit mode (e.g., draw a circle) 3. The PropertyManager sidebar displays controls inside a "Dve sheet" window (10000x10000) 4. Click any owner-drawn button: the confirm checkmark, cancel X, or circle type selectors Expected: Button fires its action (BN_CLICKED sent via WM_COMMAND to parent) Actual: Button visually depresses and releases but no action occurs Additional observations: - Standard buttons in normal-sized windows (Command Manager toolbar, viewport overlay buttons) work correctly - Text fields, dropdowns, and checkboxes in the same PropertyManager panel work - A custom window inspector confirms the buttons are BS_OWNERDRAW (style 0x5001000B) children of the "Dve sheet" window - Manually posting WM_COMMAND with BN_CLICKED to the button's parent via an external helper process makes the buttons function correctly, confirming the parent is listening for the notification This suggests the issue is in Wine's button control or mouse capture handling when the owning window has very large dimensions (10000x10000). Window hierarchy (from EnumChildWindows inspection): "Dve sheet" [AfxWnd140u] size=10000x10000 "Circle" [Button] style=0x5001000B size=242x24 ← broken "dvePage ScrollView" [AfxFrameOrView140u] size=243x798 [#32770] style=0x52000044 size=240x407 (various controls: buttons, checkboxes, labels) [Button] style=0x5001000B size=24x24 ← broken (confirm/cancel) System: macOS 26.3, Apple Silicon (M-series), Wine 11.0 stable, Rosetta 2 translation This may also affect the X11 driver — not tested. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59478 --- Comment #1 from Gijs Vermeulen <gijsvrm@gmail.com> --- *** Bug 59479 has been marked as a duplicate of this bug. *** -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59478 Anish Jindal <anishjindal08@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |anishjindal08@gmail.com --- Comment #2 from Anish Jindal <anishjindal08@gmail.com> --- (In reply to junkwalkers from comment #0)
Created attachment 80468 [details] Window hierarchy dump from inspector tool
SolidWorks 2025 Education Edition hosts PropertyManager controls inside a child window titled "Dve sheet" sized 10000x10000 pixels. Owner-drawn buttons (BS_OWNERDRAW, style 0x5001000B) inside this window visually depress when clicked (WM_LBUTTONDOWN is delivered) but the BN_CLICKED notification (WM_COMMAND) is never sent to the parent window on mouse release.
Steps to reproduce: 1. Install SolidWorks 2025 in a clean wineprefix 2. Open a part and enter sketch edit mode (e.g., draw a circle) 3. The PropertyManager sidebar displays controls inside a "Dve sheet" window (10000x10000) 4. Click any owner-drawn button: the confirm checkmark, cancel X, or circle type selectors
Expected: Button fires its action (BN_CLICKED sent via WM_COMMAND to parent) Actual: Button visually depresses and releases but no action occurs
Additional observations: - Standard buttons in normal-sized windows (Command Manager toolbar, viewport overlay buttons) work correctly - Text fields, dropdowns, and checkboxes in the same PropertyManager panel work - A custom window inspector confirms the buttons are BS_OWNERDRAW (style 0x5001000B) children of the "Dve sheet" window - Manually posting WM_COMMAND with BN_CLICKED to the button's parent via an external helper process makes the buttons function correctly, confirming the parent is listening for the notification
This suggests the issue is in Wine's button control or mouse capture handling when the owning window has very large dimensions (10000x10000).
Window hierarchy (from EnumChildWindows inspection): "Dve sheet" [AfxWnd140u] size=10000x10000 "Circle" [Button] style=0x5001000B size=242x24 ← broken "dvePage ScrollView" [AfxFrameOrView140u] size=243x798 [#32770] style=0x52000044 size=240x407 (various controls: buttons, checkboxes, labels) [Button] style=0x5001000B size=24x24 ← broken (confirm/cancel)
System: macOS 26.3, Apple Silicon (M-series), Wine 11.0 stable, Rosetta 2 translation This may also affect the X11 driver — not tested.
Testing on linux with a wine 10.x based branch (the 3D rendering fails to initialize on 11.x and I don't want to go to the trouble of bisecting right now), seems like native comctl32 does get around this bug, though it introduces some minor black-bar rendering errors. As far as the bug itself with wine's comctl32, it looks like the underlying WM_LBUTTONUP event is only sent at the start of the *next* mouse-down. So, when the mouse clicks a different button, LBUTTONUP gets sent, but the cursor is now out of range and no BN_CLICKED fires. Curiously, double click events are sent just fine. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
participants (1)
-
WineHQ Bugzilla