Simplify wxComboCtrl code by always using wxPopupTransientWindow if it's
available instead of various platform-specific workarounds that
shouldn't be needed any longer.
See https://github.com/wxWidgets/wxWidgets/pull/2423
Move definitions of wxTE_XXX flags that can be used with the controls
other than wxTextCtrl to wx/defs.h, as wxFormBuilder generates code
using them without including wx/textctrl.h, so that this code doesn't
compile.
This was already addressed in 2970f22a89 (Include <wx/textctrl.h> from
<wx/combobox.h> for compatibility., 2012-03-25) for wxComboBox, but it
also happened for wxSpinCtrl, so fix it once and for all by always
defining these styles.
This partially reverts the changes done in c57e33394c ([...] moved
wxTextCtrl-specific stuff from defs.h/event.h to textctrl.h, 2001-07-29)
as it turns out, 20 years later, that this wasn't such a great idea.
See #14132.
Closes#19225.
Use the same scaling function as elsewhere instead of using
ceil/floor().
Provide wxRescaleCoordWithFrom specialization for int to allow using it
with just single coordinates too.
They're probably not that useful in application code, which should just
use wxDPIChangedEvent::Scale() instead, so move them to a private
header instead of making them part of the public API.
This is more concise and less error-prone than multiplying/dividing DPI
values manually.
No real changes except, maybe, in wxSlider code where the rounding was
done differently before for some reason.
This wrapper simply combines the calls to MakeAbsolute() and
GetFullPath(), but using it results in shorter and more clear code, so
it seems to be worth having.
Using wxFileName::Normalize() with default flags could be surprising and
result in bugs in the code, as shown by our own wrong use of it in
wxFileSystemWatcher corrected in the previous commit.
Deprecate using it without any flags and recommend using MakeAbsolute()
instead.
Also improve the related parts of the documentation.
Unlike the parent commit, this one does change the behaviour by not
applying some normalizations any more, but these changes are correct,
i.e. we really don't need to call Normalize(), which expands environment
variables in the file names by default, here and just want to make the
file paths absolute.
In particular, this fixes the problem of mangling file names containing
dollar signs in wxFileSystemWatcher.
Closes#19214.
This gcc version claims support for this attribute, but actually doesn't
support it and returns unclear errors when it is used, e.g.
$ echo '[[deprecated]] int x;' | g++-5 -fsyntax-only -x c++ -
<stdin>:1:1: error: expected unqualified-id before ‘[’ token
so disable its use with gcc < 6.
Add yet another wxDEPRECATED_XXX macro, this one simply expanding to
C++14 [[deprecated]] attribute if it's available and nothing otherwise.
It's a bit ridiculous to have so many different macros for deprecating
things, but the new one is useful because the standard attribute can be
used to deprecated enum elements, which is impossible with MSVC-specific
__declspec(deprecated).
This seems to work fine with current version of wxPopupTransientWindow
and wxPU_CONTAINS_CONTROLS style and allows to drastically simplify the
whole mess of preprocessor checks in wxComboCtrl code, reducing the
logic to just 2 cases: either wxUSE_POPUPWIN == 1 under any of the major
platforms and then we use wxPopupTransientWindow or wxUSE_POPUPWIN == 0
or we use some other platform and then a TLW-based fallback is used
instead.
In spite of the amount of changes, this should only modify behaviour
under MSW where wxPopupTransientWindow is used now instead of whatever
was used before.
This is not as much of a simplification as the previous two commits
because there is no simple replacement of EVT_MOUSE_EVENTS() using
Bind() and a loop over all mouse event types has to be written
explicitly, but it still avoids the need to allocate and delete a
separate object, so is still worth it.
There is no need to use a separate wxEvtHandler here when we can just
use Bind() to directly handle the child text control events in
wxComboCtrlBase itself, this code was a left over from pre-wx3 days.
No real changes, just make the code simpler and smaller (and also
marginally more efficient at run-time).
This function was always called after calling CreateTextCtrl() and
couldn't be called at any other moment, so it didn't make much sense to
have it as a separate function, just install the custom input handler
when (re)creating the text control.
This simplifies the derived classes code.
The new method is currently supported in Qt, Cocoa, MSW ports (i.e. all
major ones except for wxGTK).
Keyboard example updated with a "Repeat" column.
Closes https://github.com/wxWidgets/wxWidgets/pull/2414
Drawing Bézier curves is supported natively in SVG so these curves
should be used instead of generic wxDC implementation based on
polygonal approximation.
Add an assert to this function checking that the index is valid before
using it with wxGridOperations::GetLineStartPos(), and actually avoid
calling the function when this is not the case to avoid assertion
failures when wxEVT_GRID_CELL_LEFT_CLICK is handled in user code.
Also add comments clarifying the preconditions for calling various
drag-related functions.
Closes#19218.
Instead of implementing MSW-specific code to handle HDC for GDI+ context
directly in wxGCDC delegate acquiring/releasing HDC to underlying
wxGraphicsContext. Decoupling GDI+-specific code from wxGCDC will allow
us to implement handling HDC in other graphics renderers in a clean way.
Allow using wxPrintf() etc with std::string_view arguments when using
C++17.
This is inefficient but still more convenient than not being able to use
string_view at all.
Define these functions in the class declaration to avoid gcc warning
about "redeclaring them without dllimport attribute after being
referenced with dll linkage".
This commit just moves the existing code around, no real changes.
Closes https://github.com/wxWidgets/wxWidgets/pull/2400
They were incorrectly interpreted as mnemonics when drawing
wxCheckListBox items, which didn't make sense and was inconsistent with
the other ports and even wxListBox in wxMSW itself.
It also affected wxRearrangeCtrl under MSW, which uses wxCheckListBox
for its implementation.
Closes#19201.
wxOVERRIDE was already used for the native MSW version, but not the
other ones, which prevented this header from compiling cleanly with
-Wsuggest-override and so broke allheaders test in these ports.
Closes https://github.com/wxWidgets/wxWidgets/pull/2396
There doesn't seem to be any reason to only forward CHAR events, but not
KEY_{DOWN,UP} ones, so do the same thing for the latter ones too.
This allows to get rid of GetMainWindow() call in wxDataViewCtrl unit
tests, as wxEVT_KEY_DOWN are now correctly received in the control
itself and not just its main window.
This makes several methods that didn't have any effect before work
correctly, including SetToolTip(), whose effect is now shown in the
sample, but also SetCursor() and SetLayoutDirection().
Some methods would now actually work too well: SetForegroundColour() and
SetBackgroundColour() implementations in wxCompositeWindow apply to all
sub-windows, but in wxDataViewCtrl they are only supposed to affect the
items, but not the header, so we need to override them to prevent the
base class version from being used. It is still preferable to explicitly
disable these two methods and inherit all the other ones (including any
possibly added in the future) from wxCompositeWindow to implementing all
the methods manually in wxDataViewCtrl itself.
Use the just added wxEventObjectOriginSetter to set the event object and
ID to that of wxCompositeWindow itself, rather than that of the child
window where the event had actually occurred.
This RAII helper can be used to temporarily change the event object and
ID of a wxEvent and will be used when redirecting events to make events
from one object to appear as coming from another one.
We already disabled the warnings inside windows.h, but since bf5090bcf3
(Enable Winsock 2 and IPv6 build options by default, 2021-04-24) we
could get warnings from winsock2.h, so move its inclusion inside the
region where the warnings were disabled too.
For the record, the warnings were, rather surprisingly, C4668, which is
disabled by default, but apparently was enabled somewhere inside (at
least some versions of) SDK headers.
This commit is best viewed with --color-moved git option.
