Fix FRED play/media button transparency and disabled state#7524
Merged
Conversation
Goober5000
added
fix
Goober5000
force-pushed
the
fix/button_colors
branch
from
2447d00 to
0956b55
Compare
Goober5000
force-pushed
the
fix/button_colors
branch
from
0956b55 to
3c93597
Compare
Goober5000
changed the title
CButton::SetBitmap blits a bitmap verbatim and does not perform the
magic-color substitution MFC applies when loading toolbar bitmaps. So a
button bitmap's background -- the legacy C0C0C0 gray baked into play.bmp
et al., or a magenta transparency key -- was drawn literally, reading as
a dark/colored rectangle instead of matching the real button face
(~F0F0F0 on modern Windows), and a disabled bitmap button embossed its
whole opaque rectangle into a solid gray square.
Add load_button_icon() to management.{cpp,h}, which builds an icon from
a button bitmap by keying out a background color into a transparency
mask. Driven through BS_ICON/SetIcon, the OS blends it with the button
face and grays it correctly when disabled. Route every play/media button
through it (event editor, briefing, debriefing, command brief, music
player, sound environment). Also add load_btnface_mapped() -- a
toolbar-style color remap -- kept as a lighter alternative for
always-enabled buttons.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Goober5000
force-pushed
the
fix/button_colors
branch
from
3c93597 to
57e8e1b
Compare
wookieejedi
approved these changes
Jun 15, 2026
wookieejedi
left a comment
wookieejedi
left a comment
Member
There was a problem hiding this comment.
Everything looks good to me
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
CButton::SetBitmap blits a bitmap verbatim and does not perform the magic-color substitution MFC applies when loading toolbar bitmaps. So a button bitmap's background -- the legacy C0C0C0 gray baked into play.bmp et al., or a magenta transparency key -- was drawn literally, reading as a dark/colored rectangle instead of matching the real button face (~F0F0F0 on modern Windows), and a disabled bitmap button embossed its whole opaque rectangle into a solid gray square.
Add load_btnface_mapped() to management.{cpp,h}: it loads a bitmap via CreateMappedBitmap, remapping the standard toolbar colors (background keys, shadow, highlight, text) to the live GetSysColor() values. Route the event editor's play button and the music player's play/stop/next/prev buttons through it.