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.
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.
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.
This header doesn't really need to be included from here and it was done
solely in order to get the value of wxALWAYS_NATIVE_DOUBLE_BUFFER from
it.
Move the code using this macro in the .cpp file instead.
This prevented TAB navigation from doing anything at all when the focus
was on wxComboCtrl in wxGTK and, probably, all the other non-MSW ports
(in wxMSW TAB navigation happens before normal key processing, so this
check was irrelevant there).
It is often useful to know where is the focus coming from, for example
to determine if was in another window of the same composite control.
Remember the last focus in yet another global variable in wxGTK code to
allow setting wxFocusEvent::m_window correctly when generating
wxEVT_SET_FOCUS events.
The old wxEVT_SEARCHCTRL_{SEARCH,CANCEL}_BTN event names were unwieldy
and misleading because both of these events can be generated without
using the buttons, but by pressing Enter or Esc (the latter currently
works under macOS only, but this could change in the future).
Set background style to indicate that wxSearchButton is painted entirely
by its wxEVT_PAINT handler.
This should eliminate potential flicker under MSW.
This event doesn't make any sense for this control, was never generated
by the native macOS version and couldn't be generated under MSW neither
as it's only supported by the multiline control and not the single-line
version used here, so having this code in wxSearchCtrl just made no
sense at all.
Make it possible to bind to just wxEVT_SEARCHCTRL_SEARCH_BTN under all
platforms: previously, it was also necessary to bind to wxEVT_TEXT_ENTER
when using the generic implementation, as pressing Enter in the text
control didn't generate the dedicated SEARCH event.
It does now, and, to avoid any confusion, the control does not generate
wxEVT_TEXT_ENTER events at all any more. This is not really
incompatible, as wxOSX never generated these events anyhow and the
generic version only did for a couple of days, since the changes of
9816970797 which were, finally, misguided
and so are undone by this commit.
Closes#17911.
There doesn't seem to be any need for painstakingly translating STC font
weight to DWRITE_FONT_WEIGHT when they seem to use exactly the same
numeric values anyhow.
This also fixes compilation when using older SDK versions that don't
define DWRITE_FONT_WEIGHT_SEMI_LIGHT constant, which is relatively
recent (and presence of which can't be easily checked, as it's an enum
element and not a preprocessor constant).
This was broken because wxSearchCtrl inherited the base class version of
ChangeValue() which didn't really work for it due to the poor way in
which wxTextEntry is designed (see #18071).
Closes#16998.
This was useless as wxCompositeWindow, from which the generic
wxSearchCtrl derives, already sets focus to its first child and, since
the last commit, even harmful as it now resulted in calls to SetFocus()
from inside wxEVT_SET_FOCUS handler which is forbidden at least under
MSW.
See #15569.
wxCompositeWindow already connected to child wxEVT_KILL_FOCUS events and
generated the same event for the composite window itself, but didn't do
it for wxEVT_SET_FOCUS, resulting in not getting these events for the
main window as expected. E.g. this resulted in never getting any
wxEVT_SET_FOCUS events for wxSearchCtrl when using its generic version
(i.e. not under Mac).
Fix this by connecting to wxEVT_SET_FOCUS events for the children too.
Note that this relies on having a correct "previously focused window" in
these events, if this doesn't work reliably for some ports, we might
need to maintain a "bool m_hasFocus" field in wxCompositeWindow itself
instead.
Also note that we might avoid having all this code in wxCompositeWindow
if we translated the underlying native focus event to wxFocusEvents for
both the real window and its GetMainWindowOfCompositeControl() if it's
different. This could potentially be simpler and would definitely be
more efficient, but would require more changes.
Closes#15569.
The change of 2a8c290e0d was wrong as it
unconditionally restored m_oldClipRect in dtor, even when it was empty,
indicating that no clipping had been in effect when wxDCClipper was
constructed. This totally broke all the code using wxDCClipper, notably
generic wxListCtrl which wasn't repainted correctly at all.
Fix this by checking if the clipping rectangle is not empty before
restoring it, this should work as well as we can make it without having
GetClippingRegion() that could return an invalid region if no clipping
is in effect.
See #13834.
Closes#18066.
