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.
wxGetWinVersion() will return wxWinVersion_Unknown for any MSW version
not recognized by the version of wxWidgets used when building the
application, so it makes sense to use a value higher than all currently
known ones for this constant, so that the checks comparing the result of
wxGetWinVersion() with any known version would still work correctly.
E.g. comparisons like wxGetWinVersion() >= wxWinVersion_Vista will now
continue to work for binaries built using the current wxWidgets even
under some future Windows 11 OS version, unlike before.
The include/wx/msw/private.h header contains a violation of the C++
standards that MSVC tolerates but Clang/LLVM does not.
WinBase.h contains the definition:
#define INVALID_HANDLE_VALUE ((HANDLE)(LONG_PTR)-1)
Which wxWidgets uses in:
template <wxUIntPtr INVALID_VALUE =
(wxUIntPtr)INVALID_HANDLE_VALUE>
The (effective) reinterpret_cast-ing of INVALID_HANDLE_VALUE in
WinBase.h means that the define isn't actually usable as a constant
expression for the template parameter.
Clang has indicated they have no intention of adding an MSVC
compatibility workaround for this problem. See LLVM bug 12116:
https://bugs.llvm.org/show_bug.cgi?id=12116
Given this, rework the wxWidgets header to remove the default
template parameter value (it is not used anywhere).
With this change, it's possible to compile wxWidgets applications
using Clang/LLVM (5.0) under MSVC.
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.
This is an implementation detail, don't confuse the user with this
template class which isn't supposed to be used in the user code.
Also improve the example in the documentation, the old one (using pen of
width 0 but with a colour) didn't make much sense.
Should work for Caret, still has a problem with the transformation matrix otherwise, too many things have changed there for me to find a quick solutions.
Using popupMenuPositioningItem leads to several problems on modal dialogs - the validation and action callbacks are not used, thefore we revert in this situation to using the older API, see #549 and https://trac.wxwidgets.org/ticket/17459
Prior to 2.9.2, if the focus bitmap was specified but current one wasn't, the focus bitmap was used for hovering as well.
This feature was entirely discarded in b4354db179 (see wxBitmapButton::DoSetBitmap) but it is still described in the documentation of wxButton's states and images. It seems it was removed unintentionally, so let's restore it.
Some current input processing flags, like DLGC_HASSETSEL, should be retained because they are in use (in wxWindowMSW::SetFocusFromKbd() for instance).
Closes#17945.
GetEntitiesParser()->GetCharForCode(NBSP_UNICODE_VALUE) in the non-unicode
build returns the value '?' as it doesn't find a match for that value. The
parser then proceeds to replace all '?' characters in the HTML document with
NBSP.
Change the type of the #define to be unsigned int rather than wxChar for
non-unicode to fix this.
Closes#17692.
Menus on Mac use automatic menu enabling, meaning that the system will enable
menu items only if the app responds to the menu item action. If I understand
correctly, the responder chain for menus in popup dialogs stop at the dialog
window, so the system thinks that the app does not handle the menu items.
This fix should not affect existing code since the wxWidgets user-facing API
dictates that apps specifically disable menu items.
Fix#17459
See Apple docs on automatic menu enabling at
https://developer.apple.com/library/content/documentation/Cocoa/Conceptual/MenuList/Articles/EnablingMenuItems.html#//apple_ref/doc/uid/20000261-BAJBFGED
