We already check that IsOk() returns true before calling these methods,
there is no need to do it again inside them.
Generally speaking, private functions may rely on public ones doing the
precondition checking.
It must use wxGenericAnimationCtrl as the base class in wxRTTI, as
otherwise wxAnimation::IsCompatibleWith() would fail in this case for
the generic implementation of wxAnimation.
API of wxAnimationCtrlBase practically forces the derived classes to
have such method, so just add it and make GetAnimation() a simple
non-virtual accessor.
Simplify and streamline animation classes relationship: wxAnimation is
the only public class representing an animation and it can be created by
both the native wxAnimationCtrl and wxGenericAnimationCtrl using the new
public CreateAnimation() method.
Replace wxAnimationImplType enum with more flexible type info based
check.
This is just unnecessary and having wxAnimation::m_refData->m_refData is
confusing, both in wxGTK version where it's not used and in the generic
one where it is, but can be replaced by more type-safe m_decoder.
When font family of a private font is retrieved with call to
Gdiplus::Font::GetFamily() then later on there is thrown access violation
exception when array of cached private font families (filled in by
Gdiplus::PrivateFontCollection::GetFamilies()) is deleted in
wxGDIPlusRenderer::Unload(). Call to Font::GetFamily() is done in
wxGDIPlusContext::GetTextExtent() so this issue can be seen once text
extent is retrieved for a private font.
Because it looks that calling to Font::GetFamily() for a private font is
messing up something in the array of cached private font families so
we should avoid calling this method and directly fetch corresponding font
family from the cache instead.
Reference to the cached font family would be stored in
the wxGDIPlusDataFont and it could be fetched from there directly instead
of making a call to Font::GetFamily().
Closes#18704.
This allows to easily test for the native control existence and also
whether wxGenericAnimationCtrl is really different from wxAnimationCtrl.
It also allows to avoid explicit check for wxGTK in common code.
Line height calculation based on the font size is not right for wxGTK3
because native buttons (used as in-line editor buttons) don't scale down
well and they are not displayed properly within the line.
Minimal button size when the label is displayed properly is 35 so this
has to be minimal line height under wxGTK3.
Closes#18715.
For the sake of consistency with editor buttons created with
wxPropertyGrid::GenerateEditorButton(), the borders around the buttons
should be taken into account while positioning the buttons
in wxPGMultiButton.
Because the size of the text (usually) shown in the grid changes, the
size of its columns/rows should change as well when DPI changes. Scale
them by the DPI ratio if necessary, i.e. if any of them were set to
non-default values to achieve this.
Note that this is not ideal because it can result in rounding errors and
hence in slight change of row/column size when moving the grid window to
another display with a different DPI and then back, but to prevent this
from happening we'd need to store the column/rows sizes in DIPs inside
wxGrid and convert them to actual physical pixels everywhere, which
would require much more changes. Still, if the round trip problems turn
out to be a real problem in practice, we probably will need to do this.
Also note that this doesn't take care of the grid with a native header,
but this will be addressed by upcoming commits.
This handler redoes wxGrid layout and refreshes it to at least avoid
ugly display artifacts when moving wxGrid window between displays with
different DPI.
Since the changes in a40acbb28e (Add CanOverflow function to
wxGridCellAttr, 2020-02-06), cells with non-default vertical alignment
didn't overflow any more, even if their horizontal alignment was
unchanged and still defaulted to left-aligned.
This was due to assuming that if the alignment of wxGridCellAttr itself
was different from wxALIGN_LEFT, it meant that it wasn't left-aligned,
which seems logical but is in fact false, as the alignment can also be
wxALIGN_INVALID, in which case the real alignment is taken from the
default grid attribute.
Fix this by using GetNonDefaultAlignment() to get the alignment value
effectively used and add a unit test, as well as an example in the
sample, showing that this now works correctly.
