Closed NQNStudios closed 6 days ago
This doesn't break the Linux behavior.
I checked and this also doesn't break anything on Mac OS.
These changes didn't fix the scenario and character editors, though...
Would be bad practice to leave something broken in the editors when there's a known solution, so I applied the same fix to them and it worked.
I think issue #59 must be related to the same underlying cause (stuffing a menu bar into an SFML window making it squish its effective viewport weirdly). So I might as well see if that's still a problem and try to fix that too.
@CelticMinstrel I'm done fiddling with this one if you don't have any other changes in mind.
I assume you checked that this doesn't break anything on Mac or Linux, right?
Yeah I did
On Tue, Jun 25, 2024 at 6:24 PM Celtic Minstrel @.***> wrote:
I assume you checked that this doesn't break anything on Mac or Linux, right?
— Reply to this email directly, view it on GitHub https://github.com/calref/cboe/pull/367#issuecomment-2190255029, or unsubscribe https://github.com/notifications/unsubscribe-auth/AATXBKJH7YE2KRGTDKO7IKLZJIC4FAVCNFSM6AAAAABJSYZZ6OVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCOJQGI2TKMBSHE . You are receiving this because you authored the thread.Message ID: @.***>
Fixes #366
This bug was unbelievably hard to track down and fix.
I think it was probably caused by a change in SFML's code for handling window resize events on Windows. When we add the menubar to the window by bypassing SFML and using the Windows APIs, SFML now detects that change and shrinks the logical viewport of your window without expanding the window itself to fit the menubar in it.
I updated
menuProc()
to catch that first unwanted resize event and discard it. I also made the window expand to fit the menubar's additional height, handled for a rare edge case where the menubar needs more than 1 row for its buttons, and made sure the splash screens still render in the right places.I need to test this on Linux and Mac to make sure it didn't break those.