Hi all,
I would like to ask about some possibly strange behaviour I encountered while writing a simple search facility in a StyledTextCtrl widget;
For the backward search the following simple code works for me:
editorSTC.SearchAnchor()
editorSTC.SearchPrev(searchFlags, searchedText)
editorSTC.EnsureCaretVisible()
(repeatedly called function containing this code procedes while searching backwards untill the first match is reached)
However, the complementary function SearchNext() cannot be used in the same way - it keeps finding only the first match from the original caret (or selection start) position.
This seems to be a documented behaviour, it is also mentioned in http://www.yellowbrain.com/stc/searching.html
“SearchAnchor sets the search start point used by SearchNext and SearchPrev to the start of the current selection…”
(This is ok for repeated backward search, but not realy for the forward search.)
I only found some probably quite a dirty workaround for this - for the forward search it requires:
caching the original caret and anchor position (in case nothing will be found);
then the selection is removed and the caret is set to the end of the previously selected match;
SearchAnchor() then sets the needed new starting position for SearchNext();
in case nothing (more) is found, the eventually cached selection is restored.
I was wondering, if I am not missing some obvious setting or a simple way for doing this; or is this function by design supposed to be used like this?
(I was also a bit surprised, that the matched text from SearchNext has the caret at the beginning of the selection instead of the end, but it is a minor visual detail, that can be handled easily.)
I only found some probably quite a dirty workaround for this - for the forward search it requires:
caching the original caret and anchor position (in case nothing will be found);
then the selection is removed and the caret is set to the end of the previously selected match;
SearchAnchor() then sets the needed new starting position for SearchNext();
in case nothing (more) is found, the eventually cached selection is restored.
I was wondering, if I am not missing some obvious setting or a simple way for doing this; or is this function by design supposed to be used like this?
I think that this is the intended way it is to be done.
···
--
Robin Dunn
Software Craftsman http://wxPython.org Java give you jitters? Relax with wxPython!
Hi,
thanks for the answer!
I recently checked the search function of some text editors and it seems to me, that it is actually more appropriate to use the slightly more sophisticated version for the backward search too, since the search is probably expected to start at the caret position, rather then at the selection boundary (if present).
I only found some probably quite a dirty workaround for this - for the
forward search it requires:
caching the original caret and anchor position (in case nothing will be
found);
then the selection is removed and the caret is set to the end of the
previously selected match;
SearchAnchor() then sets the needed new starting position for SearchNext();
in case nothing (more) is found, the eventually cached
selection is restored.
I was wondering, if I am not missing some obvious setting or a simple
way for doing this; or is this function by design supposed to be
used like this?
I think that this is the intended way it is to be done.
–
Robin Dunn
Software Craftsman http://wxPython.org Java give you jitters? Relax with wxPython!