When this style is specified, TAB has to be handled manually as well and
we do it by calling our Navigate() method explicitly. But for it to work
correctly we need to pretend that it's called in response to a real TAB
press by specifying FromTab flag and the code forgot to do this -- just
add the missing flag to fix it now.
In particular, this ensures that the special code handling radio buttons
in wxControlContainer::HandleOnNavigationKey() is really executed and
fixes a bug with pressing TAB on a wxTextCtrl with wxTE_PROCESS_ENTER
before a radio button group would select the first radio button of this
group instead of jumping to the currently selected button.
Closes#18392.
After bd650ec and cad2b9c, showing a popup menu in wxTextCtrl with
wxTE_RICH2 and then dismissing it without choosing a command would
result in the cursor flickering between arrow and beam cursors until
another context menu was shown.
See https://github.com/vslavik/poedit/issues/483
Fixed by checking if the popup menu is still valid (and so shown) in
the cursor handling code.
Check whether wxTextCtrl has focus using Win32 ::GetFocus() instead of
by comparing FindFocus() with "this" pointer, as the latter fails when
wxTextCtrl is part of a composite control, such as wxSearchCtrl.
This is enough to make pressing TAB in wxSearchCtrl correctly go to the
next control instead of just beeping.
Note that we could also use DoFindFocus() here, but this would be
needlessly less efficient as we don't really need to find wxWindow
corresponding to the focused HWND, as that function does. But we can't
use HasFocus() here as it wouldn't work correctly here when the focus is
on another sub-window of a composite control also containing this
wxTextCtrl.
We need to explicitly generate this event from the char hook handler as
we don't get the normal WM_CHAR for it, it is apparently intercepted by
the window proc installed by the auto-completing code, so check if
wxTE_PROCESS_ENTER is used for the text entry and call a special new
MSWProcessSpecialKey() method to do the right thing if it is.
Similarly, handle Tab presses correctly if wxTE_PROCESS_TAB is used.
Closes#12613.
New line is not always marked by 2-character (\r\n) sequence. It can be
also 1-character (\r) for RichText controls or even no mark at all (for
wrapped line).
This reverts commit c4e1fb4ef9.
Last position is not necessarily the number of characters in the buffer,
rich edit controls still store the text using CR LF between lines, but
GetLastPosition() should return the position as if they used only LF to
be consistent with all the other positions in these controls and
changing this broke existing code passing GetLastPosition() to other
functions taking position.
There is a valid position after the last character of the text in
wxTextCtrl, e.g. position 0 in the empty control, so account for it and,
notably, don't return -1 from XYToPosition(0, 0) when the control is
empty.
This fixes a regression in a69ab2907c.
Check if character position is not past the line.
When calculating (x,y) for given character position there is necessary
to take into account that for multi-line control each line (but last one)
is ended by 2-character end of line mark. Each character of this
2-character mark has a different position in the text buffer but is mapped
to the same (x,y) coordinates.
When calculating character position for given (x,y) there is necessary
to verify if passed coordinates are sane and return error status (-1) if
not. y-coordinate has to be in the range [0..numLines-1] and x-coordinate
cannot exceed the length of the text in the given line.
The native EDIT control doesn't handle this key combination, but RICHEDIT does
and people just expect it to work, so handle it at wxMSW level.
Closes https://github.com/wxWidgets/wxWidgets/pull/300
Skipping the event is supposed to have the same effect as not handling the
event at all, but in wxMSW wxTE_PROCESS_ENTER style must be specified for a
wxEVT_TEXT_ENTER handler to be executed at all and if this style is used, then
the default handling in MSWProcessMessage() which normally happens before
calling the handler doesn't take place at all.
Work around this by explicitly performing the default "Enter" key action if
the event generated by it wasn't handled to make wxMSW behaviour more
intuitive.
Override newer and more flexible virtual method: this doesn't change anything
yet but will allow to provide default handling for some messages in a single
overridden method in the future commits, when it would have required to also
override MSWDefWindowProc() with the old method.
Since the changes to use IRichEditOleCallback in wxMSW wxTextCtrl (i.e.
bd650ec3d9 in master), wxEVT_CONTEXT_MENU was
not sent for it any more as the control consumed it after using the callback.
Send the event manually before the default handling takes place to fix this.
We don't need to change the selection if we're interested in the attribute of
its starting position, as is typically the case because this is also the
cursor position, because EM_GETCHARFORMAT returns the attribute of the first
character of the selection and not, as was apparently believed when this code
was written, only the attributes which are the same for the whole selection.
This avoids flicker when constantly using GetStyle() to check for the format
at the cursor position as the selection is not changed all the time any more.
Windows CE doesn't seem to be supported by Microsoft any longer. Last CE
release was in early 2013 and the PocketPC and Smartphone targets supported by
wxWidgets are long gone.
The build files where already removed in an earlier cleanup this commit
removes all files, every #ifdef and all documentation regarding the Windows CE
support.
Closes https://github.com/wxWidgets/wxWidgets/pull/81
A wxTextCtrl inside an RTL window in an otherwise LTR application should still
be considered RTL, it's not clear at all why do we need to ask the application
for the layout here, so change this for consistency.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@78235 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
This class doesn't really need a virtual dtor as it's never used
polymorphically, but add it to avoid g++ warnings about it.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@77747 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
MinGW headers declare the IRichEditOleCallback interface and the
corresponding IID, but the libraries don't contain the latter symbol.
Work around it by defining it ourselves.
Fixes#16340.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@76771 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
In wxMSW, use IRichEditOleCallback::GetContextMenu() to provide our
default context menu for rich text controls, instead of using
EVT_CONTEXT_MENU.
The latter completely overrides native control's handling and in
particular breaks Windows 8's builtin spellchecking support.
Fall back to the previous non-OLE code for older richtext versions.
Also make the new MSWCreateContextMenu() method virtual so that the
context menu can be customized.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@76723 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Don't test for wxUSE_NORLANDER_HEADERS, this is always true since many, many
years.
Remove tests for gcc version < 3.3, notably 2.95: the minimal supported gcc
version is 3.4.
Closes#15727.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@76549 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Most importantly, this allows us to remove all MSLU-related stuff.
Some functions which were previously loaded dynamically can now be just used
directly, too.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@76535 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Don't support this compiler any more, this allows to get rid of tons of
MSVC6-specific workarounds, in particular we can now use Bind() and natural
template functions calls in the library code.
Also remove MSVC6 project and solution files and don't generate them when
bakefile_gen is ran any more (removing the remaining occurrences of msvc6prj
from the bakefiles results in weird bake-time errors, so it's simpler to just
leave them there).
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@76532 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Allow calling this function not only from inside DoWriteText(): first, because
the existing code could be doing this (although this is only a concern in 3.0
branch as it was made private in the trunk) and second because it could
actually happen if the text limit was exceeded by user typing in the control.
See #15980.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@76413 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
There is no need to do it as this is done by DoWriteText() and
AdjustSpaceLimit() doesn't work correctly if called from outside of it now.
Because of this, also make it private to prevent other accidental calls to it.
Closes#15980.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@76412 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Native text control sends EN_CHANGE when the font changes, producing a
wxEVT_TEXT event as if the user changed the value. This is not the case,
so supress the event.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@76210 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
