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.
To determine which wxSpinButton arrow was clicked, in the action handler there is compared current NSStepper value (after the actual change) with the value before the change. This former value is fetched in the internal mouse click event handler which is invoked before the action handler. This method of determining a delta works fine as long as the current value remains unchanged between the execution of the internal mouse click event handler and the action handler. But if the current value is explicitly changed (by calls to SetValue(), SetRange()) in some handler(s) invoked between these two (like e.g. bound EVT_LEFT_DOWN handler), calculated delta can be invalid and therefore wrong EVT_SPIN_DOWN/UP events can be sent.
To get correct delta value we should to keep track of all explicit changes made to the current value starting from the mouse click and up to the entry to the action handler.
Closes#17955.
SetSelections was clearing the previous selection, invalidating the
current item, but didn't set it after selecting the new items.
This was causing issues in keyboard selection, e.g. pressing Shift+click
didn't select all the items between the selected and the clicked ones.
Fix this by making the last item of the new selection current, which is
the expected behaviour considering that SetSelections() should be
equivalent to calling SetSelection() with all items one by one.
Signed-off-by: Anil Kumar <anilkumar8753@gmail.com>
Closes https://github.com/wxWidgets/wxWidgets/pull/557
Using smart array class is better than using ad hoc scope guards for
freeing memory in any case, but in this particular case it also helps to
avoid g++ 7 -Wnoexcept-type warnings due to type of free() changing to
become "void(*)() noexcept" in C++17.
Starting with version 3.5, Scintilla implemented a newer method for
handling timers and used this method in its Windows, GTK+, Cocoa, and Qt
ports. This patch attempts to bring the timer handling for wxSTC in line
with those other ports.
Closes#17949.
Don't refresh the control unnecessarily after inserting the first child
node when using modern (i.e. post-XP) MSW version, this just slows down
inserting of the first child item in big trees.
Closes https://github.com/wxWidgets/wxWidgets/pull/555
This replaces the changes of 24c0401e81
which, for some reason, used a global variable for storing whether the
selection function had been already set or not, when this clearly is a
per-control (or per-selection, but this seems one and the same) bit of
information.
Replace global ms_firstTime with a wxDataViewCtrlInternal field to avoid
asserts as soon as EditItem() is called on more than one wxDataViewCtrl.
Closes#17946.
This is a helper method used only in wxWidgets itself and only once, so
just inline it at the point of use to avoid exporting an unnecessary
function in the public API.
It doesn't make much sense to require all the graphics backends to
create wxGraphicsPen from either wxPen or wxGraphicsPenInfo when the
former can be handled just once in the common code.
So do just this, leaving CreatePen() overload taking wxGraphicsPenInfo
where the real pen construction takes place and implementing
wxGraphicsPen creation from wxPen in the common wxGraphicsContext code.
This is not 100% backwards-compatible as any code inheriting from
wxGraphicsRenderer and overriding its CreatePen() will now be broken,
however this should be extremely rare (there is no good reason to
inherit from this class in the user code) and result in compile errors
if it does happen.
