Verify that constructing wxCaret using its default ctor and Create()
works too, now that it does -- previously it uses to result in a GTK
warning and a crash in wxGTK.
Also update the test to avoid assuming that wxBitmapComboBox inherits
from wxComboBox, which now allows it to build (and pass) on all
platforms.
Closes https://github.com/wxWidgets/wxWidgets/pull/2057
In case an image without alpha is pasted on top of an image with alpha,
the alpha blending gives wrong results. This is caused by the fact that
the final (if nothing has been pasted yet) pixel copying algorithm in
Paste() does not take into account whether the pasted image actually
uses a mask.
To fix this:
- Add the check for image.HasMask().
- In case there is no mask, simply copy the image via memcpy.
- Finally, update the alpha channel of the changed image (if present):
whenever a pixel is copied, the alpha is set to fully opaque.
Closes https://github.com/wxWidgets/wxWidgets/pull/2065
Add the source files present in the bkl but not CMakeLists.txt to the
latter one too.
Also link with AUI library now that a test file using it is included.
Closes https://github.com/wxWidgets/wxWidgets/pull/2064
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.
