Subtracting a huge negative offset from the current position could
overflow it, which was correctly detected as undefined behaviour by
UBSAN.
Credit to OSS-Fuzz: this solves its issue 4388.
Although the object being created _will_ be of type wxAppConsole, it
doesn't have this type yet, as wxAppConsole ctor hadn't yet run, and so
the static cast is invalid and detected as such by UBSAN in g++ 6.3.
Allow wxPrintf("%1$s %1$s", "foo") to work.
Take into account the possibility that the number of format specifiers
and the number of actual arguments can be different.
Closes#9367.
Probably a follow-up fix for commit from 10 years ago: 288b610
This fixes compilation with `--enable-extended_rtti` configure flag.
Also removed all trailing spaces in this file.
Replaced `wxToStringConverter<type, data, result)` with
`wxFromStringConverter<type>(data, result)`, which was broken
for 7 years since the commit 13830d6
This fixes compilation with `--enable-extended_rtti` configure flag.
Also removed all trailing spaces in this file.
Handle this feature as all the other ones and provide a configure switch
and a setup.h option to disable it if necessary, as it may be desirable
to do it, especially under Linux, to avoid extra dependency on pangoft2
if this functionality is unnecessary.
Use wx_is_at_least_gtk2(minor) instead of gtk_check_version(2, minor)
because it is more clear and also works as expected (i.e. returns true)
when using GTK+ 3 instead of creating difficult to notice bugs in the
code by failing the version check in this case.
See #18004.
Unfortunately there is no reasonable way to implement this function for all
glibc versions as the information we need is stored in the private
_GOptionGroup struct whose layout has already changed once (in 2.44) and could
change again, so we can't rely on it.
We really need a g_option_group_get_entries() in glib itself, but the request
to add it at http://bugzilla.gnome.org/show_bug.cgi?id=431021 hasn't been
touched since 10 years, so it seems unlikely to happen.
See 99367a1530 (commitcomment-25789514)
When column resizing is finished, after HDN_ENDTRACK notification there is
also sent one (and last) HDN_ITEMCHANGING notification. We have to skip it
to prevent from sending EVT_HEADER_RESIZING after EVT_HEADER_END_RESIZE
because EVT_HEADER_END_RESIZE should be really the last one event
in the sequence of resizing events (like it's assumed in wxGrid).
Closes#16390.
Ever since the changes of 544c4a3bde
(almost 14 years ago), playing mono WAVs with wxSound completely failed
if setting the sound device to mono using SNDCTL_DSP_STEREO ioctl
failed. This doesn't look like a wise thing to do, so don't consider
this as a fatal failure, but just play mono as stereo (and even possibly
stereo as mono) instead.
This fixes the sound sample being broken out of the box on many (all?)
Linux systems.
The code was completely broken as it locked the mutex in only one thread
and then tried to unlock it in another one, which made no sense, didn't
protect against anything and resulted in errors and assert failures.
Fix this by locking and unlocking the mutex in both threads before
accessing shared data or playing sound.
Closes#17990.
It seems to have been replaced by wxSoundPlaybackStatus::m_playing a
long time ago but was still kept, resulting in confusion and always
returning false from IsPlaying() as it tested a wrong variable.
Fix this by removing this one completely and always using the other one
everywhere.
Remove maximal reallocation size in wxArrayString too, as it was done
for wxVector a commit ago, and increase its size by 100% and not 50%
when it needs to grow.
There is no real reason to use different growth strategies in the two
classes and wxVector one seems to be better.
Call assign() instead of Add() in a loop: this is not only shorter, but
also ensures that reserve() is called before starting the loop and all
the required memory is allocated at once.
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.
Cut down on release archives size, somewhat, by excluding third party
libraries that we're never going to use.
The exception is libtiff which references all its files in its configure
that we do run and it's probably not worth to bother with paring it down
if this means maintaining changes to configure.
Verify that the active loop didn't change during this object lifetime as
otherwise we could deactivate a different event loop from the one we
installed.
It's still a programming error to write code which doesn't destroy
wxGenericProgressDialog early enough, but at least now "just" assert and
leak memory in this case instead of resetting the active event loop and
hanging the program.
Closes#17983.
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.
