Fix using outdated click position in wxAuiTabCtrl mouse handlers, which
resulted in an invalid wxEVT_AUINOTEBOOK_DRAG_MOTION event being
generated and a crash while handling it.
Ensure that we reset m_clickPt when resetting m_isDragging too so that
we don't decide that we're dragging if the mouse enters the window with
the left button already pressed after a previous drag.
See #24027, #24039.
(cherry picked from commit f1a3816cd9da0c3c7ceebe9735d37fb2d3158388)
When the original messages language matches the language of the locale
being used, these strings can be used directly and so AddCatalog()
should still return true for them but it didn't do it any more after the
changes of 94b1a17aeb (Add AddAvailableCatalog() and use it in
AddStdCatalog(), 2023-09-30).
See #18227.
Closes#24019.
Closes#24037.
(cherry picked from commit 39079cbf237e1a93a2acd97280cc2845a811f819)
While these array classes are deprecated in the user code, they're still
used, for compatibility, in many places in wxWidgets API and allowing to
create them from initializer_list makes using it more ergonomic as it's
now possible to just pass an initializer list of items to fill the
control with, for example, instead of appending them one by one.
This is the equivalent of 4d62df488b (Add support for initializer_list
to wx dynamic arrays, 2023-03-02) from master.
See #23309.
Closes#23966.
This reverts the frame synchronization logic that was recently added
with the purpose of avoiding performance issues due to `eglSwapBuffers`
blocking when the canvas is hidden or occluded.
This logic should be unnecessary after `eglSwapInterval(display, 0)`
is called, since `eglSwapBuffers` should never block anymore.
Furthermore, as it stands now, it causes the canvas to continuously
repaint itself at the refresh rate of the display, which is wasteful
for applications which do not need to continuously refresh.
See #24012, #24017.
(cherry picked from commit abfdd186ff540e62d18ef3e3d37ce2015843309a)
Change implementation to use Sonoma-supported version of the application
activation call.
See #23893, #24003.
(cherry picked from commit 695ca042895468a8ce6c1a84422882adb3c63ee9)
In the recent changes for handling map/unmap events on Wayland's
wxGLCanvasEGL, we use the following GTK widget signals:
* The "map-event" signal to create the canvas's subsurface.
The earlier "map" signal can not be used, as the associated toplevel
window's Wayland surface may not yet exist by the time we receive it.
* The "unmap" signal to destroy the canvas's subsurface.
Using the later "unmap-event" signal is problematic, due to other
resources we build upon being already destroyed by then.
Usually, the "map-event" signal comes before "unmap" and resources are
created and destroyed appropriately. However, there's an edge case:
If a canvas is shown and then immediately hidden (before wxWidgets can
pump from the event loop), "unmap" will come before "map-event".
This happens because signals like "map" and "unmap" are delivered
immediately (when calling e.g. `gtk_widget_hide`), while signals like
"map-event" and "unmap-event" are delivered later on the event loop.
For the same reason, showing a canvas, then immediately hiding it, then
immediately showing it again, will cause two "map-event"s to get
delivered enqueued without a "unmap" in between.
This condition can be hit quite easily when setting up a complex UIs,
and in particular it is triggered by Aegisub during startup, leading to
a crash (Wayland protocol error) when opening a video later, or when
specifying a video directly on the startup command line.
To avoid this breaking our resource management, add some checks to detect
those "map-event"s we shouldn't handle - either the ones that happen
after "unmap", or the duplicate ones without an "unmap" in between.
See #23961, #23968.
(cherry picked from commit 133f7731b25df46bd99519e7c52cf4a90ca2cc1a)
If the wxGLCanvas is destroyed immediately (without hiding it first),
the GTKs widget's `unmap` signal which usually destroys the Wayland
resources is not emitted. Thus, we need to ensure they are destroyed
on the destructor instead.
This fixes an use-after-free issue, sometimes causing a crash, because
one of the leaked resources is the canvas's Wayland frame callback.
See #24013, #24016.
(cherry picked from commit 22ae7a58b5412463194b446426296b588368bff8)
Calling it from the frame callback might change the swap interval for
the wrong context if the active context got changed in the meanwhile,
but by the time SwapBuffers() is called the correct context must be set.
Doing it there also allows to unify X11 and Wayland code branches.
See #24014.
(cherry picked from commit 64afa9d96341f3696ba5311d36fd3a82f7c9de77)
Don't use m_readyToDraw in it, as the canvas is still shown even when
it's not ready to draw yet, and use m_wlSubsurface instead as it is
destroyed when the window is unmapped.
See #23899.
(cherry picked from commit cf44a87ec62f9cefb428b8d6c002c2ee342dc4ec)
No real changes, just clean up the code a bit to make sure we get a
-Wswitch if any elements are added to wxDisplayType enum in the future.
(cherry picked from commit d128afe1e8fff6fbd16c46ffbe30eaba706ff274)
The memory leak fix in b52728a62a (Fix memory leak of wxClipboard data
on exit, 2023-06-21) was too eager and destroyed not just the currently
used selection (e.g. primary), but also the other one (secondary) when
Clear() was called, which was wrong and resulted in the loss of
clipboard contents when discarding the primary selection in wxSTC, for
example.
Fix this by only deleting the object corresponding to the selection
which we're clearing.
See #23661, #23988.
(cherry picked from commit dc6a0c069bdde714f22cb0459efd9ad186ce7179)
Changing the selection could behave wrongly and result in an assert
failure as the selection anchor could have become invalid, due to the
change of the number of items in the control.
Fix this by invalidating it when this happens.
(cherry picked from commit 5885eea5ea72434311f2c706f57cff92a09ade91)
The leak check is done before the FlsAlloc()-installed callback function
runs in this build variant and so reports wxThreadSpecificInfo object,
and everything it contains, as leaked, even if it isn't, really, so
deallocate it explicitly ourselves in this case.
Also call wxThreadSpecificInfoTLS::CleanUp() from the main thread as
well, which fixes a possible real (albeit one-time only, so not really)
memory leak under XP where FLS API is not available.
A console program should not really be linked with the GUI library, but it used
to work, and it's unavoidable with the monolithic build, so fix the regression.
See #23981
(cherry picked from commit 4cabfa111ab5912ae30d6d44b917a9c403845b3f)
Correct the too hastily backported change of cb69e76897 (Fix not
refreshing generic wxListCtrl after deleting last item, 2023-10-06)
and use NULL instead of nullptr in this branch.
Mark it as deprecated in the documentation without deprecating it
formally in the code, as it seems to be used in some existing code and
there is no urgency to remove it, but using it in new code still doesn't
make any sense.
See #23945.
(cherry picked from commit 543fd3fabcb6d88a6e220520c41501c3f961dd55)
The check for the line being deleted being in the visible range
prevented us from refreshing anything at all if the line which was just
deleted was the last line of the control.
(cherry picked from commit 8d036af8160d303b67944d781d27ff58b058f839)
These patterns are supposed to match all files and not only files with
extensions, but our own code only matched the latter.
Switch to using shell PathMatchSpec() function to check for matching
instead to use the usual Windows rules.
See #23905, #23910.
(cherry picked from commit a4d2e36cec16d511e461496f3eecbcb6f3e7343b)
The new function only returns true if the catalog could be really
loaded and not if it is considered not to be needed because the message
ID language (which is typically "en-US") happens to be present in the
preferred UI languages list (which seems to always include "en-US" in at
least Western European MSW).
This allows to distinguish, albeit in a rather awkward (but
backwards-compatible) way between having a translation for the given
language and not needed such translation.
It is still not clear if it is really correct to return "en-US" from the
list of preferred languages even if the user has never intentionally
configured the OS to indicate that English is acceptable, but at least
now we can work around this issue and use AddAvailableCatalog() in
AddStdCatalog() to make sure we only skip loading unversioned wxstd.mo
if the versioned wxstd-x.y.mo file is really found instead of never
doing it, as was the case until now (see #23886).
Also add GetBestAvailableTranslation() helper which seems more useful
than the existing GetBestTranslation() one and is similarly related to
it.
See #18227, #23930.
(cherry picked from commit 94b1a17aeb12a1ec723a255089be16cd31a268a2)
When the wxWidgets sources are in a path containing '++', CMake would
show errors on the command line:
[cmake] RegularExpression::compile(): Nested *?+.
[cmake] RegularExpression::compile(): Error in compile
This happens because the full path was interpreted as a regular
expression when creating the source_groups. Without wxSOURCE_DIR the
regular expressions still match and create correct source groups, so
remove it.
See #22738, #23943.
(cherry picked from commit b9b0724de141696edf817fb032aa51daf699b48b)
Remove any remaining mouse messages from the input queue after showing
the file dialog because they somehow remain after it is destroyed and
could be processed by the application once wxFileDialog::ShowModal()
returns, resulting in phantom events being processed by the controls
that just happen to be under the button of the file dialog that was
clicked to close it.
See #10924, #23944.
(cherry picked from commit ffc99bd487731629308af9af79205003b7d7e3b0)
