WM_CONTEXTMENU message is generated directly by the system when the user presses and releases the VK_APPS key so there is no need to do this by emulating right mouse button click.
Closes#17969.
When mouse is captured somwhere in the application, it's recommended
to have implemented a EVT_MOUSE_CAPTURE_LOST handler.
Resetting in the handler flag signalling captured state seems
to be a sufficient action because something like this is implemented
in the native Scintilla and it works fine in SciTE.
Closes#17961.
At least under wxMSW and wxGTK opening a popup menu when mouse is captured
generates EVT_MOUSE_CAPTURE_LOST. We would like to avoid this and
to release capture in a controlled way.
See #17961.
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.
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.
wxBitmap should be made transparency-capable before copying wxIcon bits to it. Doing so when wxIcon bits are already copied seems to work fine for OSX 10.8, but not for newer versions.
Closes#17953.
Do compile wxEntry(void) overload used in wxIMPLEMENT_WXWIN_MAIN_CONSOLE
expansion by non-MSVC compilers under MSW inside the monolithic library
too by replacing the "#if !wxUSE_GUI" check guarding it with "#if
wxUSE_BASE" one.
It's not really clear how could this have ever worked without this fix
before, although it apparently did, but stopped with gcc 7.
At least in wxMSW wxPen::GetStipple() returns a non-null (but invalid)
bitmap even when pen style is not wxPENSTYLE_STIPPLE, so don't test for
this bitmap when creating a wxGraphicsPen from a wxPen but for the style
directly.
This avoids using this invalid bitmap later in D2D code, where it
resulted in assert failures.
Also add a similar style test before calling wxPen::GetDashes() for
consistency, even if it doesn't seem to be strictly necessary.
See https://github.com/wxWidgets/wxWidgets/pull/553Closes#17958.
When replacing m_OutlineView with a new one in ClearColumns(), we must
explicitly remove the old one from its superview to ensure that no more
drawing operations are pending for it. Without this change, Cocoa
drawing code would occasionally crash on attempting to message the
now-zombie m_OutlineView instance. This happened in older macOS
versions too, but became much more frequent in 10.13 High Sierra.
