Don't shift by m_SystemMadeBy value which can potentially be an
arbitrary (8 bit) integer and not necessarily one of the known (and
small) wxZIP_SYSTEM_XXX values, this results in undefined behaviour
whenever this value is greater than 32 or 64 (depending on int size) and
is flagged as such by clang undefined behaviour sanitizer.
To fix the problem, just use a more clear switch statement instead of
using a bit pattern for the lookup, this function is not nearly
performance-sensitive enough to worry about the overhead of the switch
here (assuming it's even slower, in the first place...) and the new
version is much more clear and maintainable.
Credit to OSS-Fuzz: this solves its issue 3792.
Provide native implementation of this function instead of using the ad hoc one
in common code, which didn't really work -- so remove it completely now.
Closes#17189.
Fix comparing items with checkboxes in wxTreeListCtrl and make it
simpler to correctly implement item comparison in other
wxDataViewCtrl-derived classes.
See https://github.com/wxWidgets/wxWidgets/pull/558
When extra style bits are set with the call to
wxPropertyGridManager::SetExtraStyle(), only those which are relevant
to wxPropertyGrid should be passed to the underlying property grid object.
Because it can happen that not all extra style bits of the underlying
wxPropertyGrid have been effectively changed by call to SetExtraStyle()
(e.g. wxPG_EX_NATIVE_DOUBLE_BUFFERING), we have to get the actual style
bits prior to storing them.
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.
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.
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.
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.
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.
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.
The latest of those checks tested for w32 API 3.3, which is older than
MinGW 3.4 released which is more than 13 years old, so we can safely
drop them (let alone checks for prehistoric 0.5 w32 API).
This incidentally fixes compilation errors due to the use of
wxCHECK_W32API_VERSION() in wx/msw/winundef.h which was now (since
the changes of 8c572c0a77) included before
this macro was defined.
If neither wxCAL_SUNDAY_FIRST or wxCAL_MONDAY_FIRST was given, use
wxDateTime::GetFirstWeekDay() to automatically determine the preferred
day.
This changes the earlier default behaviour, which was to use Sunday
if not otherwise specified. However, the wxGTK native calendar control
ignored this behaviour anyway.
This function tries to determine the preferred first day of week to use in
calendars. The procedure for obtaining this information is highly
platform-dependent, and is not possible on all platforms; in that case
Sunday is used as the fallback value.
Implementations are included for MSW, OSX, and Linux.
This method seems completely unnecessary, the base
wxTextEntry::DoSetValue(), which delegates to Remove() and WriteText(),
seems to work just as well and avoids code duplication between this
method and wxTextCtrl::WriteText().
Notice that gtk_text_buffer_set_text() is just a trivial wrapper around
gtk_text_buffer_delete() and gtk_text_buffer_insert() anyhow, so there
is no efficiency loss in not using it neither.
Fix compilation/link problems due to symbols redefinitions in user code
that could happen if it included some wx header first, then <windows.h>
(possibly indirectly, e.g. via another third party library) and then
another wx header -- in this case, the second wx header wasn't protected
from <windows.h> redefinitions resulting in all the usual problems.
Avoid this by always including winundef.h whenever any wx header is
included, not just when wx/defs.h is included for the first time.
