Vcpkg defaults to installing packages for x86-windows, and from the
perspective of x64 builds, the packages installed just cannot be
found -- and the reason is not very obvious.
Having an example with commands that will install both x86 and x64 is
probably the right thing to do in this day and age -- and if somebody
only wants one and not the other, seeing a package name with architecture
specified helps with guessing how to achieve that.
Closes#22075.
We often need the logical bitmap size when using it in size computations
involving window size, so add a function returning it directly to
wxBitmapBundle, similarly to wxBitmap::GetLogicalSize(), to avoid using
FromPhys() everywhere.
Also rename the existing wxBitmapBundle::GetPreferredSizeFor() to
GetPreferredBitmapSizeFor() to make it more clear that this is similar
to wxBitmap::GetSize() and so returns the size in physical units.
Closes#22056.
These functions have better names than the existing GetScaledXXX() ones,
so add them to be able to use them in the new code, even if we still
keep the old ones for compatibility.
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>
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.
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.
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.
In section "dependency" use "*" in processorArchitecture instead of specifying
the concrete architecture such as "amd64" or "x86". This allows to have just one
manifest for all architectures instead of having them for all supported architectures
individually differing in just processorArchitecture.
Also don't duplicate this information in both how-to-add-new-sample.md
and how-to-add-files-to-build-system.md, just reference the former in
the latter instead.
Also fix some Markdown markup.
These accelerators are not shown in wxMenuItem label, but still will
work.
Implement support for them in all major ports and XRC.
Co-Authored-By: Vadim Zeitlin <vadim@wxwidgets.org>
It may not be obvious how to build the tests, so add a section
explaining this to the existing file containing the instructions about
writing the tests and add a README to the tests directory itself to
increase chances that this file will be found -- hopefully anybody
interested in the tests will look at the README in the directory
containing them.
We need to be able to change the scale factor of the bitmaps returned by
wxBitmapBundle::GetBitmap(), so add a function allowing to do this.
Also add wxHAS_BITMAP_SCALE_FACTOR allowing to check whether this
function actually does something non-trivial and explain in the docs
that GetScaleFactor() always returns 1 on the platforms where this
symbol is not defined.
Unlike the existing wxHAS_IMAGES_IN_RESOURCES constant defined only
under MSW, the new one is also defined under Mac and could be defined
for the other platforms/ports later (e.g. wxQt could probably support it
too).
It's unfortunate that two very similar constants are needed, but it
doesn't seem wise to change the meaning of the existing constant, as
this would change how the commonly used wxICON() and wxBITMAP() macros
behave and would break all our own samples that use them for their frame
icon but don't embed this icon into the bundle resources under Mac.
Do change the toolbar sample to use the new constant however, as this
one does include the bitmaps it uses in its bundle under Mac.
This comes at the price of breaking compatibility and returning
"\\share" rather than just "share" from wxFileName::GetVolume() for the
UNC paths. This breakage seems justified because it is required in order
to allow application code to distinguish between paths "x:\foo" and
"\\x\foo", which was previously impossible as GetVolume() returned just
"x" in both cases.
Document this change, adjust the existing checks for the new GetVolume()
semantics and add a new test which passes now, but didn't pass before.
Closes#19255.
This commit is best viewed ignoring whitespace-only changes.
Te changes of 74c51eaff2 (Fix formatting of wxMSW build instructions,
2021-07-13) broke the rendered output of "%WXWIN%", for some reason the
leading percent sign needs to be double to appear correctly inside the
backticks, so do it to fix this.
Closes#19260.
Don't say that the application needs to be compiled with the same
__WXDEBUG__ value, as this is not true since 3.0 days.
Also link the debugging overview.
