This method allows to exclude a top level window from screen captures.
Windows 7 or newer is required and any macOS version is supported.
Other platforms are not implemented and will return false.
The display example has been extended to demo this ability.
Closes#22066.
SetIncrement() was already available in wxSpinCtrlDouble and GTK version
of wxSpinCtrl, now implement support for it in wxMSW and wxOSX as well.
In fact, in wxMSW, implement it at wxSpinButton level, so that both this
class and wxSpinCtrl inheriting from it (in wxMSW only) support setting
custom increment now.
Also add support for it to XRC, show it in the sample and add a unit
test verifying that it works.
Closes#2597.
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.
Performance tweak for samples/display, resulting in a much faster
application start, particularly when built in debug mode, when Windows
messages are dumped to the system debug channel for
inspection/diagnosis.
Speed up the Append() loop below by foregoing the repeated resizing of
the choice drop-down via repeated calls to GetBestSize() which happens
deep inside the Append() call chain and executes another inner loop
calling SendMessage() to get the control contents. (This exhibits
1/2*O(N^2) behaviour thanks to the linear growth of the length of the
inner loop to the length of the outer loop (= number of items to add),
while it is re-executed for every new added item.)
With the 'display' sample, that's about 500+ rounds and about 500*500/2
SendMessage() calls less now on my dev/test rig, taking noticeable time
to start the display application.
---
Issue was found due to the barrage of '(winmsg)' Windows Message debug
log lines zipping by in the monitor app when the sample was build in
Debug Mode. Only significant difference with the Release Build is those
debug lines being output, hence the performance gain is less, but still
measurable, in a Release build. When the machine is otherwise severely
loaded (UI render core maxing out), "measurable" becomes "obnoxiously
noticeable" again on Win10/64.
Closes#22049.
Extend the existing use of wxIcon in wxDataViewIconText,
wxDataViewCheckIconText, the corresponding renderers and
wxDataViewTreeCtrl to wxBitmapBundle.
As with the other classes, the existing setters have been preserved as
they remain almost entirely compatible with the existing code and the
return type of the existing getters was preserved, with new getters
being introduced for returning wxBitmapBundle only where they're really
required.
Update the sample to use wxBitmapBundle with its wxDataViewTreeCtrl.
Embed SVG data of the wx logo into the library itself to make it
available to all wx programs, including the samples. This is a bit
wasteful, but <12KiB is not really noticeable compared to the library
size.
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).
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.
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.
This sweeps under the carpet the regression which resulted in bitmaps
returned from wxArtProvider::GetBitmap() not looking the same since
starting to use wxBitmapBundle in AUI, but OTOH it just doesn't seem
possible to both preserve the compatibility and allow actually using
appropriate, not scaled, bitmaps in different resolutions.
The new code is as simple as the old version, follows the official
advice to use GetBitmapBundle() rather than GetBitmap(), and looks good
in high DPI, which should compensate for the behaviour change.
wxAuiToolBar::SetToolBitmapSize() doesn't do anything and never did ever
since it was added back in 1154f91b6a (added wxAuiToolBar, 2008-08-24),
so don't bother calling it, this just makes the sample code confusing as
no effect from passing different sizes to SetToolBitmapSize() can be
seen during run-time.
To enable fullscreen support with WKWebView private API which was
available since macOS 10.11 was used. Beginning with macOS 12.1 this
resulted in unpredictable layout issues inside the webview.
This reimplementation using java script and message handlers does only
use public API. This also makes the fullscreen message more controlable
as the webview does no longer put the containing window in fullscreen
mode without application code intervention. That also unifies macOS with
the way Edge sends this event in MSW.
Closes https://github.com/wxWidgets/wxWidgets/pull/2629
Using a const char* and a wxString in the two branches of the ternary
operator resulted in compile-time errors since the result type of the
conditional expression was ambiguous, so add explicit conversions to fix
it.
Closes https://github.com/wxWidgets/wxWidgets/pull/2634
See #19355.
It seems like this function will need to be used in every implementation
of EVT_LIST_COL_CLICK handler when using sorting, so it makes sense to
provide it in the library itself.
