I took another pass through the current implementation and I don't think this issue is actionable as written.
wxSP_NO_XP_THEME is documented as disabling Windows theming for the splitter, giving the border and sash the pre-XP look. The current MSW renderer code already does that: wxRendererXP::GetSplitterParams(), wxRendererXP::DrawSplitterBorder(), and wxRendererXP::DrawSplitterSash() all route the wxSP_NO_XP_THEME case to the non-XP delegate renderer, while the themed path uses the XP-style button-face sash.
Inverting the condition would make the code contradict the documented meaning of wxSP_NO_XP_THEME, and would also risk making splitter geometry and drawing disagree because GetSplitterParams() and the draw methods are intentionally using the same flag split.
The existing discussion also leaves the intended change unresolved. Without a concrete reproducer showing the current behavior is wrong, I think this should either be closed as not reproducible/actionable or retitled with a specific visual mismatch to fix.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you authored the thread.![]()