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.
No real changes, but just use string concatenation instead of line
continuation backslashes and also replace hard TABs with spaces.
Notice that the code is still completely unreadable as JavaScript, but
this shouldn't be a problem as nobody will see it there anyhow, so it's
quite enough to have it more readable in its string form in C++.
We can prepare the escaped code directly here, instead of waiting for
GetWrappedCode() call, this is more clear and safer as it avoids
escaping the code twice accidentally if GetWrappedCode() ends up being
called twice somehow.
While it is allowed there, it is confusing and unnecessary.
Also improve the comment explaining why do we need this output variable
name at all and why does it need to be unique.
This is a non-standard extension in the first place and the variable
name didn't make any sense too, so rename it to be standard-conforming
and actually correspond to what it contains.
There is no need to check that calling MSWSetModernEmulationLevel()
changed the registry key in the test, this is just an implementation
detail of this function.
This makes it unnecessary to define wxIE_EMULATION_LEVEL and
wxREGISTRY_IE_PATH (which are both badly named) in the public header.
Finally, improve the error message in MSWSetModernEmulationLevel() and
add another one for failing to reset the emulation level too.
This helper function runs a JavaScript script and blocks until it
finishes executing, so try to use a name at least hinting at this
instead of being totally generic and useless.
Include wx headers using quotes, not angle brackets.
Wrap over long lines.
Don't put space between the function name and its arguments.
Make wxJSStringRef::ToWxString() itself, not its return value, const.
Improve comments.
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.
