This reverts commit d26758044c which was a
workaround for the problem of wxWakeUpIdle() dispatching events, as this
is not the case any more after the latest changes.
This can result in deadlocks because wxWakeUpIdle(), admittedly rather
unexpectedly, can result in dispatching a message in the main thread,
which could reacquire the same lock again.
Native wxMSW dialog split the provided message into the title and body
in Update(), but didn't do it for the initial message specified when
constructing the dialog, resulting in weird jumps, due to the font size
change between the body and title dialog elements, if the updated
message differed just slightly from the initial one.
Fix this and refactor the code to reuse the same function for doing this
splitting in both places.
Use TDM_UPDATE_ELEMENT_TEXT even for the initial update as this allows
to specify the message of roughly comparable (or greater) length than
the messages that will be subsequently used while the dialog is shown
and avoid size changes later, which is much more natural than having to
do it for the first call to Update().
No real changes, just don't lock a critical section for a short time
only to lock it again almost immediately after unlocking -- just combine
both blocks for which it is locked into one, there is no reason to
release it for TASKDIALOGCONFIG and wxMSWTaskDialogConfig initialization
which are both trivial operations not involving any callbacks.
Checking for m_progressBarMarquee is not necessary any longer, just
testing the value is enough.
Update the comments to explain why is it so.
No real changes.
This further improves the dialog usability when the main thread doesn't
update it frequently enough, as these times can be seen immediately
without having to expand the "details" part of the dialog which can be
very sluggish in this case.
It is also more consistent with the generic dialog and the behaviour of
the native dialog before 6b91c5dfab876f0f1b17d54304bfb2fda27398ef which
removed the code clearing TDF_EXPAND_FOOTER_AREA style.
Since the switch to tying the task dialog thread message queue with the
main thread, animating the progress bar didn't work well unless the
dialog was updated very frequently from the main thread and could lag
behind significantly, and confusingly for the user, otherwise.
Work around this by avoiding the progress bar animation and setting it
immediately to its real value. This works much better in practice.
This is actually completely unnecessary because this is done implicitly
by Windows itself anyhow when we create the dialog with the owner window
belonging to a different thread.
Notice that this also explains why the thread input can't be detached
later.
Don't bother performing the updates if nothing was requested.
And ensure that nothing is requested even more often than it already was
by not requesting an update if the new value is the same as the old one.
This is not necessary any longer now that we use the correct parent for
the dialog window, the task dialog is centered automatically.
And unlike our own code, comctl32.dll code always puts the dialog fully
on one monitor instead of making it span two of them if the parent
window does.
Don't call EndDialog() while inside the critical section, this could
(and did, sometimes) result in a deadlock if the main thread was trying
to enter it in order to send us wxSPDD_DESTROYED notification as
EndDialog() needs it to process some messages.
If Cancel/close button was pressed twice in a row, assert checking that
the dialog state was "Continue" could be triggered, which was worse than
annoying as it resulted in a deadlock due to trying to show the assert
dialog box while holding the critical section that prevented the main
thread from continuing.
Allow the state to be either "Continue" or already be set to "Canceled"
now to account for this case.
Still assert for the other invalid states, but they really aren't
supposed to be possible here.
DoGetPosition() was done in 1ef1f8fda6,
implement DoGetSize() too now in order to give a chance Centre() (which
needs both position and size to work).
See #17768.
No real changes, just prepare for implementing DoGetSize() in this class
by extracting the common part between the existing DoGetPosition() and
it in a new function.
We can just ask for the window rectangle directly from the main thread,
there is no need to update the position in wxProgressDialogSharedData
all the time.
When the "Cancel" button inside the dialog is disabled, disable the
close title bar button as well as it serves the same purpose.
In particular, this avoids asserts when clicking the close title bar
button while showing the confirmation message box asking the user
whether the dialog should be cancelled in the dialogs sample.
This ensures the correct relationship between wxProgressDialog and its
parent window, fixing different problems with Z-order and the progress
dialog icon, but requires attaching the progress dialog thread input to
the main thread, which creates its own problems: in particular, the task
dialog is now only updated when the messages are dispatched in the main
thread, i.e. more sluggishly than before.
It also requires taking care to avoid the deadlocks as the task dialog
thread now waits for the main thread to dispatch its messages too, as
the child dialog sends messages to the parent window. In particular, we
can't simply wait for the task dialog thread to terminate, but must do
it while dispatching the events as well.
Closes#13185.
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.
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.
Position of wxProgressDialog cannot be changed directly because the dialog is created in another thread and may exist when SetPosition() is called. New position has be stored in the data structure used to share data between the main thread and the task dialog runner and the real update is done during the cyclic refresh in the dialog thread.
Closes#13546.
Icon for wxProgressDialog cannot be changed directly because the dialog is created in another thread and may not yet exist when SetIcon() is called. We have to store new icon(s) in the data structure used to share data between the main thread and the task dialog runner and wait for a cyclic update.
Closes#17967.
In wxProgressDialog::SetTitle(), wxSPDD_TITLE_CHANGED flag signaling a request to update a title should be added to the flags already being set and signaling another data waiting for the update.
Closes#17966.
This keyword is not expanded by Git which means it's not replaced with the
correct revision value in the releases made using git-based scripts and it's
confusing to have lines with unexpanded "$Id$" in the released files. As
expanding them with Git is not that simple (it could be done with git archive
and export-subst attribute) and there are not many benefits in having them in
the first place, just remove all these lines.
If nothing else, this will make an eventual transition to Git simpler.
Closes#14487.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@74602 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Use t_str() instead of wx_str() to make the code work correctly in UTF-8 build
in which wx_str() returns a pointer to UTF-8 buffer while we need a wchar_t
pointer for Windows.
Closes#14371.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@71640 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
The progress dialog parent was supposed to become the new foreground window
when the progress dialog was closed, but this didn't happen because
m_parentTop was never set when the native progress dialog implementation was
used under MSW. Fix this by explicitly calling the new SetTopParent() from its
ctor.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@70512 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Don't call GetParentForModalDialog() with wxProgressDialog style, this doesn't
work as it expects the window style.
Do call SetParent() when using the native MSW implementation as the wx-level
parent is not used then.
Closes#13706.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@69874 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
If the message doesn't contain any new lines, it should be used as the body,
not the title as having title without body doesn't make sense and looks
strange.
Closes#13441.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@69592 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
MSWCommonTaskDialogInit() now (probably since r67620) always creates a
IDCANCEL button so don't create another one in wxProgressDialog code, just
ensure that the one created by that function has the correct label (either
"Cancel" or "Close").
Closes#13358.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@68338 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
wxProgressDialog was created without the parent when using task dialogs so it
was centred on screen and not on its parent as usual. Fix this by explicitly
positioning it so that it's centered over the parent.
Closes#12699.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@66244 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
