This allows to retrieve the native CPU architecture name regardless of
the current process CPU architecture.
Common examples for CPU architecture differences are the following:
- Win32 process in x64 Windows (WoW)
- Win32 or x64 process on ARM64 Windows (WoW64)
- x86_64 process on ARM64 macOS (Rosetta 2)
Closes#22036.
Create wxD2D1Factory with D2D1_DEBUG_LEVEL_WARNING only when debug
features, such as asserts, are enabled at wx level.
This is not the exact equivalent of the "Debug" build commonly used
under MSW with MSVC, but seems to be the closest equivalent, see the
discussion in #22034.
Closes#22039.
Use wxTE_RICH2 for a control that we call EnableProofCheck() on, as
using this function without this style asserts in wxMSW.
This should have been done in 5ba2461fd1 (Switch to using GSpell for
wxTextCtrl proof checker in wxGTK, 2021-09-08).
Also add a diagram showing the functions to use to convert between them,
perhaps this can be more clear than textual description.
Co-Authored-By: Stefan Csomor <csomor@advancedconcepts.ch>
In webview sample toolbar use wxBitmapBundles created from SVG files
instead of XPM bitmaps, as this results in much better appearance in
high DPI.
Closes#2642.
This reverts commit a34ab31453, reversing
changes made to 783df59e66.
Undo the addition of wxBitmapBundle support to XRC, as it is finally
going to be done in a different way soon -- but for now just remove it
to ensure that nobody starts using it before it's finalized.
See #2633.
Closes#22014.
Handle selectors corresponding to key presses, such as cancelOperation:,
ourselves because we never get the keyDown events that are supposed to
take care of generating it from the native code somehow.
This fixes cancelling editing with Escape which stopped working since
26d6f82a81 (Implement EVT_CHAR generation for wxDataViewCtrl under Mac,
2021-04-13).
Closes#17835, #2639.
Co-Authored-By: Stefan Csomor <csomor@advancedconcepts.ch>
Add some templates for GitHub issues.
These templates notably allow associating labels with the new issues,
which would be impossible otherwise.
See #22016.
We need to use the bitmap size in logical pixels for NSImage and we
definitely must not multiply the physical size by the scale factor, only
dividing it makes sense -- so just do it, by using GetScaledXXX()
instead of GetXXX() when creating the NSImage to use for wxBitmap.
Surprisingly, this seems to have been broken ever since the addition of
this code in 95aa8e40fd (first part of OSX adaptations, 2021-09-28)
without anybody noticing it until now.
Closes#22019.
Contrary to what the documentation stated, it was possible for the item
to be invalid, so update it to explain this and give an example of a
case in which this happens.
See #19182.
This resulted in an assert when receiving wxEVT_TREE_SEL_CHANGED events
with invalid item when the tree was recreated from wxGenericDirCtrl own
OnSelFilter().
Closes#19182.
The year is now included in the copyright string used in the makefiles
and so they need to be regenerated every time the year changes (which
happens surprisingly frequently).
It would be better to define a single variable with the year number to
avoid having to do this in the future.
Correctly set the font size to the size one bigger or smaller than the
current one instead of just setting it to size 1 in both cases.
Apparently this was broken ever since this code was added back in
4f9297b0ee (wxHTML src code indentation now conforms (more) to wxWin
coding style, 2000-11-05) without anybody noticing.
Closes#22012.
This is simpler and a tad more accurate than dividing by
GetContentScaleFactor().
Also add FromPhys() to MSW-specific code: even if it's not really needed
there (as the conversion is always trivial), it's still better to have
it for consistency.
Provide these functions for consistency with the existing FromDIP() and
ToDIP().
We also can use ceil() (rather than round() used by wxSize operators) in
FromPhys() to ensure that we never truncate contents of a physical
bitmap, which allows to replace the existing wxStaticBitmap code with
just a call to this function.
The physical size returned by wxBitmapBundle::GetPreferredSizeFor() must
be converted to logical pixels when it's used as a wxDC coordinate.
This fixes a regression introduced in 391080e77d (Use wxBitmapBundle for
AUI tab pages bitmaps, 2021-11-13).
This fixes the problem with wrong standard bitmaps size when using high
DPI for the main monitor with wxMSW, as GetScaledSize() used here since
31f2892200 (Avoid bitmap scaling in wxArtProvider::GetBitmapBundle(),
2021-12-17) was not the right function to use there.
Closes#19331.
Now wxMSW also stores the scale factor, even if it doesn't use it in its
GetScaledXXX(), so it doesn't seem useful to have this symbol for
distinguishing the platforms with and without bitmap scale factor
support, when we can just use wxHAS_DPI_INDEPENDENT_PIXELS instead in
the only place where this was used.
And as this symbol was added quite recently, in 2c1f4c002d (Add
wxBitmap::SetScaleFactor(), 2021-10-23), we can hopefully just remove it
without breaking any existing code, if we do it right now.
wxBitmap::GetScaledXXX() functions are useful for obtaining the
coordinates in logical pixels, so they should only divide by the scaling
factor on the platforms where logical pixels are actually different from
the physical ones, i.e. those using DPI-independent pixels.
This ensures that their behaviour under MSW remains unchanged even after
a1e4dca067 (Store scale factor in wxMSW bitmaps too, 2021-12-16), which
is the correct way to avoid breaking wxAUI (and other) drawing.
Using wxHAS_ prefix is more consistent with all the other similar
symbols, using wxHAVE_ was a mistake, that we have to pay for by
preserving the old name now (as it is actually already used in some code
outside of the library).
The fact that it's used also shows that it's better to document this
symbol, even if just to explain that it normally shouldn't be used, as
we can't really hide it anyhow.
