Make GTKHandleFocusOut() virtual and override it in wxChoice in order to
avoid generating wxEVT_KILL_FOCUS events when the combobox dropdown
button is clicked.
This is important because it allows fatal problems when using a
combobox-based in-place editor in wxDataViewCtrl as getting these events
totally broke the UI before.
See #17034.
Don't disable all inert renderers as this results in ugly "disabled"
look for some of them (see 6e885992f5),
but do disable the renderers that would be editable otherwise, such as
wxDataViewChoiceRenderer and wxDataViewToggleRenderer, in wxOSX as it
shouldn't be possible to change value of the inert cells.
See https://github.com/wxWidgets/wxWidgets/pull/707Closes#18056.
This reverts af16d8ba5c. It caused
problems with older git versions (e.g. 1.8.5) that do not recognize the
checkout option: warning: unknown update mode 'checkout' suggested for
submodule '3rdparty/catch' Skipping submodule '3rdparty/catch'
Also specify the branch for the catch submodule, to be in line with the
other submodules.
Composite windows, i.e. wxWindows composed of several HWNDs at MSW
level, didn't handle focus events correctly and, for example, generated
wxEVT_KILL_FOCUS event when the focus simply switched from wxComboBox
itself to the EDIT control inside it, which broke using non-readonly
wxComboBox as in-place editor inside wxDataViewCtrl.
Check if the focus event notifies about the focus switching to, or from,
another HWND belonging to the same window, and suppress wx event
generation in this case as they don't make sense because the focus
doesn't change at wx level.
See #17034.
Replace the use of wxList macros with wxVector.
Also make wxDataViewTreeStore::Compare() slightly more efficient by
iterating over the children list only once instead of doing it twice.
This is a check for a programming error and should never be shown to the
user, so assert that the items being compared in wxDataViewTreeStore are
under the same parent instead of using wxLogError.
Don't use deprecated macro-based linked list class, use wxVector<>
instead for m_notifiers.
Also make it private, as it should have been from the beginning.
This used to work in 3.0, but got broken with the switch to using a
native function for rendering the gauge in generic wxDataViewCtrl
86cf756ba9 (see #16406).
Restore it now, even if it requires not one, but two hacks: one at
wxRendererGeneric level to guess whether a custom colour is being used
or not by examining wxDC::GetBackground(), and the other one in
wxDataViewProgressRenderer itself to fall back to wxRendererGeneric if
the colour is specified. But it is arguably worth doing this to fix the
regression, even if it would be nice to provide a better API instead
(see #18076).
Closes#17885.
For consistency with wxListCtrl under MSW (which is the only platform
where this change has any effect, as wxHD_BITMAP_ON_RIGHT is only
supported there), put the column images on the right side in
wxDataViewCtrl too.
Closes#13350.
The buttons were truncated, making them look ugly, because we didn't
allocate enough space for them. Instead of complicating generic
wxDataViewCtrl code even further with more MSW-specific code, just let
DrawItemTreeButton() center the expander itself in the space allocated
for it.
This still involves guessing the width of the expander, but this doesn't
need to be done as precisely, so it's still an advantage. Note that
previously calculating expander size involved m_lineHeight, for some
reason, but now we use GetCharWidth() for it, which is more appropriate.
Closes#17863.
No event was sent if the selection was narrowed by clicking on an
already selected item without any key modifiers pressed.
Fix this by generating an event always on click and not only when
selecting a new item.
Closes#17881.
GTKHandleDeferredFocusOut() is only ever called when gs_deferredFocusOut
is non-null, so there is no need to check for it inside this function
again.
No real changes.
It was unexpected that this method could only be used for horizontal
gauges, so make it work for the vertical ones if wxCONTROL_SPECIAL flag
is specified.
Update MSW and generic implementations and the render sample to show a
vertical gauge as well.
This method is used to illustrate the difference between the default and
the overridden GetHeaderButton() implementations, but doesn't need to be
used for any other methods, that are not overridden in MyRenderer.
No real changes, but just make the code shorter and less confusing.
Skip docbook checks in Expat configure to speed it up a bit and, mainly,
to avoid the harmless but confusing
$wx/src/expat/expat/configure: line 16683: program: command not found
which was given when running it.
VS2017 environment bat files change the working directory so the build
directory is returned to after calling them.
A warning has been added that the VS150COMNTOOLS environment variable
needs to be set or a VS2017 command prompt needs to be used for VS2017
builds. MS no longer sets this variable on install.
For vc110 and vc120 builds the x64 switch has been changed to x86_amd64.
Closes#18075.
A few methods, notably including DrawFocusRect() and DrawItemText(),
were missing MSWApplyGDIPlusTransform() calls that need to be done
before drawing on an HDC corresponding to a wxGCDC object.
Add them by replacing calls to wxCopyRectToRECT() with the just added
ConvertToRECT() function, which adjusts the coordinates and copies
wxRect to RECT at once.
Combine MSWApplyGDIPlusTransform() and wxCopyRectToRECT() into a single
helper function to simplify the code and, importantly, to make it more
difficult to forget call the former function.
No real changes, this is a pure refactoring.
TAB should be used for navigation by default and only should be inserted
into the control as a literal character if wxTE_PROCESS_TAB is specified
for consistency with wxMSW and because this behaviour is much more
useful by default.
Fix this by calling gtk_text_view_set_accepts_tab() as appropriate for
multiline text controls. For single line ones, the behaviour is
unchanged but it's more reasonable as TAB is always handled as if
wxTE_PROCESS_TAB were not specified and it doesn't seem really useful to
try to support wxTE_PROCESS_TAB for them anyhow, so just document this
limitation.
Also remove the outdated/misleading documentation of this style, notably
don't say that it is required to get char events for TAB presses as
these events are generated both with and without this style in both
wxGTK and wxMSW.
Closes https://github.com/wxWidgets/wxWidgets/pull/704
This assert was especially annoying because it could be shown when
showing a previous assert message on the platforms without the native
rich message dialog (i.e. anything but MSW), resulting in reentering the
assert handler and killing the application.
Clicking outside of the items area didn't generate wxEVT_CONTEXT_MENU in
the generic version, unlike the native MSW one and contrary to
expectations.
Also update the documentation to make it clear when exactly are
wxEVT_TREE_ITEM_MENU and wxEVT_CONTEXT_MENU events generated.
Closes#17361.
Derive wxGenericComboCtrl from wxNavigationEnabled<> to make TAB work
correctly when the focus was on it, otherwise it didn't move it
correctly to the next control.
This notably allows TAB to cycle through all the controls in the "combo"
sample whereas previously it stopped on reaching the combo control with
the list popup with wxGTK.
