Since we always convert wxImage to 32 bpp wxBitmap, there is no reason to keep a separate mask for wxBitmap because alpha channel can be used directly.
Monochrome mask bitmap should have white pixels in the unmasked area and black pixels in the masked area, quite the opposite to what is implemented now.
Closes#10098.
When bitmap data are accessed with wxNativePixelData, which is designed
to handle RGB bitmaps, Alpha() function cannot be used because in this
case alpha component index is set to the default value -1 and actually
the blue component of the "preceding" pixel is accessed.
Closes#18478.
It's generally wxWidgets policy not to include platform-specific headers from our own
to avoid namespace pollution issues, in this case with names like "None" and "Window".
Getting the warnings about deprecated macros when building the library
itself is not useful, as it must continue to use them as long as
WXWIN_COMPATIBILITY_3_0 exists.
Closes https://github.com/wxWidgets/wxWidgets/pull/1510
While feacaf8714 changed the API to allow
using any wxWindow (and not only a window of a wxControl-derived class)
as the associated window of the grid editor, actually doing resulted in
an immediate crash due to dereferencing a null pointer in wxGrid code
which still expected to have a wxControl.
Fix this by replacing all calls to wxGridCellEditor::GetControl() inside
wxGrid with wxGridCellEditor::GetWindow(), to ensure that a non-null
editor window is used even in this case.
Closes https://github.com/wxWidgets/wxWidgets/pull/1509
It doesn't make sense to return anything else than an empty rectangle
when querying the icon rectangle of the sub-items that can't show any
icon.
Also document this behaviour, just in case it's not obvious.
In 8f386265dc, the width of a tree
expander is changed to the native value on the platform. But some
calculations still use guessed value (m_lineHeight) as the width. This
fixes the value, by retrieving the width using the same method as in
OnPaint().
Closes https://github.com/wxWidgets/wxWidgets/pull/1508Closes#18473.
Add preliminary support for per-monitor DPI awareness to wxMSW.
Individual controls still need to be fixed, so this support is still
experimental/unfinished for now.
See https://github.com/wxWidgets/wxWidgets/pull/1499
It causes a warning with MSVC code analysis:
"warning C26437: Do not slice (es.63)"
It's unclear if this function even needs to exist, but at least
move it out of line so the warning does not occur for user code.
wxNativeFontInfo constructor calculates the pointSize using the main screen DPI.
But lfHeight returned by GetNonClientMetrics is based on the window DPI.
Update the documentation to reflect change to the GetMenu event
working for all 3 menu events. Also update the sample to give the
menu for the highlight event.
Use wxString::StartsWith() instead of comparing the result of Find()
with 0: this is shorter and more clear (and marginally more efficient).
No real changes.
This ensures that they are always available and can be used in
wxLaunchDefaultBrowser() in all build variants, whereas before this
function didn't handle file:// URLs correctly when the library was built
with wxUSE_FILESYSTEM==0.
Closes https://github.com/wxWidgets/wxWidgets/pull/1469Closes#10414.
The various arrays containing row/column coordinates (m_rowHeights,
m_rowBottoms, m_colWidths, m_colRights) must not be accessed directly as
they are empty by default, and are only initialized if any rows/columns
have non-default width/height.
Use safe accessor functions instead.
See https://github.com/wxWidgets/wxWidgets/pull/1417
React to the WM_DPICHANGED event and update the size of the child windows and
the top-level window. Scale the minimum and maximum window size to the new DPI.
Only react to WM_DPICHANGED when DPI_AWARENESS_CONTEXT_PER_MONITOR_AWARE_V2 is
used.
This updates/replaces 6c59a4e7af which
fixed the problem with auto-resizing of wxStaticBitmap with borders, but
broke auto-resizing of wxStaticBitmap that previously used an invalid
bitmap, as they still have a non-null (currently hard-coded as 16x16)
size in this case and the size updating logic didn't take it into
account.
Instead of trying to make it even smarter, get rid of it completely and
just set the control size to its best size, as the other ports do. This
is simpler and should be less error-prone -- and won't require updating
when the constant 16x16 will be changed to something else (which will
happen soon as part of better high DPI support).
See #18398.
Commit 91aa6ba36e introduced a
regression causing this to crash. We need to validate that the color
is valid before attempting to call OSXGetNSColor; if it is not, we
should clear any previously-set background color.
Closes#18470.
Closes https://github.com/wxWidgets/wxWidgets/pull/1503
