Current DeviceToLogical{X|Y}(), LogicalToDevice{X|Y}(),
DeviceToLogicalRel{X|Y}(), LogicalToDeviceRel{X|Y}() functions
don't take into account transformations applied with
SetTransformMatrix() so conversion results are invalid if coordinate
system is e.g. rotated.
We need to implement new conversion functions that take into account all
applied transformations and also convert x,y coordinates in one call
because in general case x,y coordinates are coupled and cannot be
converted independently on each other.
Closes#18923.
Generic wxDC::DeviceToLogicalRel{X|Y}() and wxDC::LogicalToDeviceRel{X|Y}()
functions don't take into account scaling applied with
wxDC::SetTransformMatrix().
We need to implement in wxDCImpl and its platform-specific derivates
new conversion functions that take all applied transformations into account.
See #18923.
Fix variable name for the model.
Make the code using wxObjectDataPtr have the same flow as the
code using a raw pointer.
Format the code to be in accordance with the official guidelines.
Closes#18924.
Now that this class is not a template any longer, we can have the code
for radio button group navigation directly in it, without making it
inline, so move the existing functions bodies into the new methods and
remove the old functions entirely.
No real changes, this is just a refactoring.
Use a dirty hack to accommodate wxUniv by deriving wxRadioButtonBase
from wxCheckBox, rather than wxControl, there. This is not pretty, but
should be addressed by refactoring wxUniv code and in the meanwhile all
the other ports don't have to bother with using a template class
unnecessarily.
Now that we do have wxRadioButtonBase class, declare wxRadioButton API
methods as pure virtual in it, to force the derived classes to implement
them.
Also remove the outdated comment saying that there is no base class for
wxRadioButtons in different ports, this is not true any longer.
Allow creating wxWindowPtr from wxScopedPtr<> too, to avoid having to
use .get() in the test code, and add CHECK_SAME_WINDOW() macro which
gives more useful information about the windows in case of failure.
This requires adding a couple of const_cast<>s in their implementation
in order to still allow them returning non-const wxRadioButton pointers,
but this seems preferable to not being able to call them on a const
wxRadioButton in the first place.
Previously they were only used, and compiled, on the platforms without
wxHAS_NATIVE_TAB_TRAVERSAL, i.e. were not compiled at all in wxGTK, but
we now need them everywhere as they're used to implement public API.
We can't rely on HasSelection() returning true immediately after calling
SelectAll() because this operation (as almost all the other ones) is
asynchronous with WebKit and might not have completed yet when we check
for the selection existence.
There doesn't seem to be any way to wait for its completion, so just
poll the selection state for some time before deciding that it hasn't
been updated. In practice, just a couple of ms is enough on a normal
machine, but wait up to 50ms on Travis just to be on the safe side.
Note that to reliably reproduce the problem locally it's enough to run
"taskset 1 ./test_gui -c Selection WebView", i.e. pin both the main and
WebKit processes to the same CPU.
wxCmpNatural() had "inline" function specifier in a .cpp file
which made the function inaccessible outside that file in static builds.
Fix this by removing "inline", the function character is such that the
overhead by a function call should have negligible impact on its
performance.
Closes https://github.com/wxWidgets/wxWidgets/pull/2050Closes#18919.
This is a micro-optimization after the previous commit: don't call
FindToolByPositionWithPacking() at all rather than calling it and then
ignoring its result if wxAUI_TB_NO_TOOLTIPS style is set.
This commit is best viewed ignoring whitespace.
