Do this for compatibility with wxGenericProgressDialog, which always did
this and can't really do otherwise as it needs to react to the clicks on
its buttons, and also because not doing it results in the other
application windows being marked as "not responding" by MSW, which looks
bad.
Closes#17768.
Acquire the lock in wxProgressDialog::DoNativeBeforeUpdate() itself
instead of relying on the caller to do it.
This is just a refactoring in preparation for further changes.
Reset the state to "Continue" instead of assigning it the dialogs own
m_state which was also set to "Continue" from the base class Resume()
called just before, but this wasn't necessarily obvious from just
reading the code.
No real changes.
Although this doesn't change anything because, by a happy concourse of
circumstances, FALSE is the same as S_OK and TRUE is the same as S_FALSE
numerically, it is still better and more clear, because consistent with
the documentation, to return these constants from the task dialog
callback function rather than boolean ones.
Check that we do have the shared data before dereferencing the pointer
to it. While this normally will always be the case, it could be null if
some error happened, so add a check for it, just as we already do it
elsewhere.
This was accidentally copy-and-pasted from another function in
1ef1f8fda6, just remove it as it was done
for the original check in the last commit but one.
This was added in 01bd848eb9 without any
explanation and probably was a copy-and-paste typo as it just doesn't
make any sense to change the state of the dialog in this accessor
function (and if the state doesn't change, then this assignment is just
completely useless).
Remove the apparently unnecessary assignment and also an unnecessary
temporary variable.
Add the possibility to test the generic implementation of the class when
we use the native one by default, this is useful to allow comparing the
behaviour of the two classes.
It needs to be overridden in the native MSW wxProgressDialog
implementation, but was only hidden by the function with the same name
in the derived class, making it impossible to call the right function
via the base class pointer, for example.
Use a weak reference to the parent instead of a pointer to avoid
crashing if the parent TLW is destroyed before wxGenericProgressDialog
itself is. This is unlikely to happen in C++ code, where objects of this
class are typically created on the stack, but can happen in e.g.
wxPython where this is not the case.
Closes#16378.
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.
If the new message is longer than the previously shown one, increase the
dialog size to fit it, instead of truncating the message. Still don't do
anything if the new message is shorter to avoid unwanted constant
changes in the dialog size if the message keeps changing.
This is the original patch proposed in #10624, which it really makes
sense to apply now because it makes the generic version match the
behaviour of the native one under MSW (and the behaviour of the native
version cannot be changed).
See #10624.
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.
So wxNO_BORDER works with other controls, such as wxBitmapButton.
Also use GTK prefix on ApplyCssStyle(), and add an overload that
creates the GtkCssProvider.
We need to use PKG_CHECK_MODULES(pangoft2) anyhow because we need to
link with its libraries, so make the version check there too and
simplify wxFont::AddPrivateFont() implementation in wxGTK.
This test seems to consistently fail, but the failure can't be
reproduced locally nor debugged on buildbot, so, lacking any other
solution, just disable it.
Commit fc7f20c419 did fix a memory leak in
this test case, but at the price of introducing a crash due to deleting
the same pointer twice.
The real fix would be to change the code here to avoid returning a
pointer which sometimes needs to be deleted and sometimes must not, but
for now just add a crude check to avoid crashing.
There doesn't seem to be any special reason to use wxStyledTextControl
in this sample and doing it unconditionally breaks the build with
--disable-stc, so use wxTextCtrl instead in this case.
Closes#17998.
This should have been done in b8c9cd3528
to avoid all warnings about std::auto_ptr<> being deprecated when using
g++ 6 or later which compiles in C++14 mode by default.
Just "activate" the font immediately when adding it using
AddPrivateFont(), nothing seems to be gained from having two functions
and it just makes things more complicated both when implementing and
when using the API.
Use pango_fc_font_map_set_config() to associate the FcConfig containing
the private fonts with the global Pango context to make them available.
Also use FcInitLoadConfigAndFonts() instead of just FcConfigCreate() to
initialize the new config with all the default fonts instead of just
using our private fonts in it.
FcConfigAppFontAddFile() that we use is only available since 2.8, so
check for at least this version of the library in configure.
Also change the macro guarding its use to the more semantically
appropriate "wxHAVE" rather than "wxUSE" and make it more precise by
adding "2_8_0" suffix to it.
This is necessary to recognize new fonts, for example those added using
AddPrivateFont(), as being valid: otherwise they were not found in the
cache and couldn't be used in wxGTK.
Don't rely on it being done during statics cleanup as this doesn't work
if the library is shutdown and re-initialized.
Use a module to do the cleanup, just as it's already done for a lot of
other global data in wx.
This is required to allow loading private fonts from the bundle
Resources/Fonts subdirectory and doesn't seem to have any negative
consequences for the applications which don't need this functionality.
Add an explicit call to wc_str() in one place where conversion to
wchar_t* is needed and use wxString::operator==() instead of lstrcmp()
to avoid having to perform this conversion explicitly in another place.
Ensure we don't keep the values in the global gs_privateFontFileNames
variable if the library is shutdown and reinitialized later, this would
be unexpected.
This ensures that they will be defined and work even when building with
wxUSE_GRAPHICS_CONTEXT==0 (as can happen even by default with old MinGW
versions).
Private fonts are still made available to wxGraphicsContext as well by
providing access to them from GDI+ code via wxGetPrivateFontFileNames().
wxFont::AddPrivateFont() can now be used to load a font from a file for the
applications private use. Update the font sample to show this.
Closes#13568.
There's a bug in OS X 10.11 where a toll-free bridged font may have an
attributed of private class __NSCFCharacterSet that unlike
NSCharacterSet doesn't conform to NSSecureCoding. This poses a problem
when such font is used in user-editable content, because some Asian
input methods then crash in 10.11 when editing the string. As a
workaround for this bug, don't use toll-free bridging, but re-create
NSFont from the descriptor instead on buggy OS X versions.
Fixes regression introduced in a77066d530
(#507).
