wxInvalidSize is a documented return value for wxDir::GetTotalSize(),
yet it was not available by including just wx/dir.h as it was declared
in wx/filename.h only.
Fix this by declaring it in wx/dir.h too.
Closes https://github.com/wxWidgets/wxWidgets/pull/609
Also use this for wxArray::Shrink() implementation as it's more
efficient than the old swap-based implementation which requires an extra
memory allocation instead of really shrinking the existing one.
Unfortunately it doesn't seem possible to prevent the native MSW dialog
from changing its size in both upper and lower direction vertically, so
at least mention this in the documentation and mention a possible
workaround of manually adjusting the text to always have the same number
of lines.
Such dialogs must be destroyed before the main event loop starts running
to avoid problems with the temporary event loop created by the dialog
internally.
See #17983.
The dialog now grows automatically as needed and Fit() can be called to
shrink it back if desired and this behaviour is consistent under all
platforms.
This method is supposed to adjust the dialog size to its contents and
while the dialog increases automatically when using native
implementation under MSW, it doesn't shrink back on its own and so it's
still useful to allow Fit() to do it.
Update the sample to test Fit() too.
MSW implementation of wxProgressDialog adjusted the dialog size to the
size of the message shown in it on each update, resulting in visually
unpleasant constant jumping around (this is the same problem that we
used to have in wxGenericProgressDialog long time ago, see #10624).
Minimize this by using TDM_UPDATE_ELEMENT_TEXT instead of
TDM_SET_ELEMENT_TEXT for changing the element text. This still increases
the dialog size if the new element text is longer than the old value,
but at least doesn't shrink it back if it is shorter, which is already
quite an improvement.
Notice that this change requires using TDF_EXPAND_FOOTER_AREA style, as
otherwise the expanded information can't be updated without a re-layout.
But this doesn't seem to be a big loss and it's not really clear why did
we explicitly clear this flag before anyhow.
Update the dialogs sample to make it easy to test for this behaviour and
the documentation to mention MSW version peculiarities.
Mention that this method is supposed to be used only as an optimization
and also mention that it hadn't been universally available until 3.1.1.
See https://github.com/wxWidgets/wxWidgets/pull/570
Zip filenames containing non ASCII characters will be marked with
bit 11 in the general purpose flags and will use UTF-8 encoding.
By only setting the flag when non ASCII characters are used the
created archives should be binary identical to previous versions.
The old behavior can be achieved by explicitly using wxConvLocal
with the constructor. This should also ensure that
existing code using a custom wxMBConv should work as before.
Provide native implementation of this function instead of using the ad hoc one
in common code, which didn't really work -- so remove it completely now.
Closes#17189.
Fix comparing items with checkboxes in wxTreeListCtrl and make it
simpler to correctly implement item comparison in other
wxDataViewCtrl-derived classes.
See https://github.com/wxWidgets/wxWidgets/pull/558
Export this class, which was only used internally by wxTreeListCtrl
before, so that user code can use it for its own columns with custom
wxDataViewCtrl models.
It doesn't make much sense to require all the graphics backends to
create wxGraphicsPen from either wxPen or wxGraphicsPenInfo when the
former can be handled just once in the common code.
So do just this, leaving CreatePen() overload taking wxGraphicsPenInfo
where the real pen construction takes place and implementing
wxGraphicsPen creation from wxPen in the common wxGraphicsContext code.
This is not 100% backwards-compatible as any code inheriting from
wxGraphicsRenderer and overriding its CreatePen() will now be broken,
however this should be extremely rare (there is no good reason to
inherit from this class in the user code) and result in compile errors
if it does happen.
This is an implementation detail, don't confuse the user with this
template class which isn't supposed to be used in the user code.
Also improve the example in the documentation, the old one (using pen of
width 0 but with a colour) didn't make much sense.
