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.
Get rid of ugly wxDynamicCastThis()s in wxMSW wxControl code and add a
new virtual method overridden in wx{Tree,List}Ctrl instead.
Also stop comparing the font with wxSYS_DEFAULT_GUI_FONT, there doesn't
seem to be any good reason to set this particular font for these
controls neither.
In addition to simplifying and de-ugligying the code, this commit
incidentally fixes -Wnonnull-compare warnings in this code from gcc6
too.
Under MSW calling UnblockAndRegisterWithEventLoop() for blocking sockets
is not only useless, but actually harmful when the socket is used from a
worker thread (which is the common case for blocking sockets), as it
means that the main thread will be receiving notifications for the
socket events and modifying the socket object while it's being used from
the other thread, resulting in data races and general brokenness.
This is similar to e18c8fd29a for Unix
sockets.
Closes#17937.
When WM_ENDSESSION was received by the application, the wxApp object
itself was shut down by calling OnExit() on it before all the TLWs were
destroyed, which could be completely unexpected as during normal
shutdown the order of events is exactly the reverse.
In practice, this resulted in crashes in any application whose main
window close event handler or dtor touched wxTheApp in any way (e.g. to
save any configuration in the global wxConfig object destroyed by
wxApp::OnExit()).
See #9590 (sorry for missing the point before, ATS).
