Fix behaviour of wxTextCtrl without wxTE_PROCESS_TAB in wxGTK

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 commit is contained in:
Vadim Zeitlin 2018-01-30 22:12:22 +01:00
parent 193939453e
commit ad71bbb9ad
3 changed files with 26 additions and 4 deletions

View File

@ -185,6 +185,7 @@ wxGTK:
- Make wxUIActionSimulator work with GTK+ 3 (Scott Talbert).
- Make wxBORDER_NONE work for wxTextCtrl with GTK+ 3 (Adrien Tétar).
- Handle wxTE_PROCESS_TAB, and its absence, correctly in multiline wxTextCtrl.
- Apply wxTextCtrl::SetDefaultStyle() to user-entered text (Andreas Falkenhahn).
- Implement dynamic auto-completion in wxTextEntry (AliKet).
- Fix wxTextCtrl::GetStyle() with GTK+ 3.

View File

@ -945,10 +945,12 @@ public:
(otherwise pressing Enter key is either processed internally by the
control or used to activate the default button of the dialog, if any).
@style{wxTE_PROCESS_TAB}
The control will receive @c wxEVT_CHAR events for TAB pressed -
normally, TAB is used for passing to the next control in a dialog
instead. For the control created with this style, you can still use
Ctrl-Enter to pass to the next control from the keyboard.
Normally, TAB key is used for keyboard navigation and pressing it in
a control switches focus to the next one. With this style, this
won't happen and if the TAB is not otherwise processed (e.g. by @c
wxEVT_CHAR event handler), a literal TAB character is inserted into
the control. Notice that this style has no effect for single-line
text controls when using wxGTK.
@style{wxTE_MULTILINE}
The text control allows multiple lines. If this style is not
specified, line break characters should not be used in the controls

View File

@ -323,6 +323,14 @@ au_apply_tag_callback(GtkTextBuffer *buffer,
}
}
// Check if the style contains wxTE_PROCESS_TAB and update the given
// GtkTextView accordingly.
static void wxGtkSetAcceptsTab(GtkWidget* text, long style)
{
gtk_text_view_set_accepts_tab(GTK_TEXT_VIEW(text),
(style & wxTE_PROCESS_TAB) != 0);
}
//-----------------------------------------------------------------------------
// GtkTextCharPredicates for gtk_text_iter_*_find_char
//-----------------------------------------------------------------------------
@ -800,6 +808,8 @@ bool wxTextCtrl::Create( wxWindow *parent,
if (multi_line)
{
wxGtkSetAcceptsTab(m_text, style);
// Handle URLs on multi-line controls with wxTE_AUTO_URL style
if (style & wxTE_AUTO_URL)
{
@ -984,6 +994,15 @@ void wxTextCtrl::SetWindowStyleFlag(long style)
if ( (style & wxTE_PROCESS_ENTER) != (styleOld & wxTE_PROCESS_ENTER) )
GTKSetActivatesDefault();
if ( IsMultiLine() )
{
wxGtkSetAcceptsTab(m_text, style);
}
//else: there doesn't seem to be any way to do it for entries and while we
// could emulate wxTE_PROCESS_TAB for them by handling Tab key events
// explicitly, it doesn't seem to be worth doing it, this style is
// pretty useless with single-line controls.
static const long flagsWrap = wxTE_WORDWRAP | wxTE_CHARWRAP | wxTE_DONTWRAP;
if ( (style & flagsWrap) != (styleOld & flagsWrap) )
GTKSetWrapMode();