No, you are not misunderstanding, at least not completely. I literally just got that part to do that
selectionMode before: 0
moveExtendsSelection() before: false
selections before: 1
selectionStart before: 697
selectionEnd before: 697
selectionMode after: 0
moveExtendsSelection() after: true
selections after: 1
selectionStart after: 697
selectionEnd after: 697
moveExtendsSelection(): true
case Qt::Key_Period: // select
case Qt::Key_Delete:
qDebug() << "selectionMode before: " << selectionMode() << "\n";
qDebug() << "moveExtendsSelection() before: " << moveExtendsSelection() << "\n";
qDebug() << "selections before: " << selections() << "\n";
qDebug() << "selectionStart before: " << selectionStart() << "\n";
qDebug() << "selectionEnd before: " << selectionEnd() << "\n";
setSelectionMode(SC_SEL_STREAM);
qDebug() << "selectionMode after: " << selectionMode() << "\n";
qDebug() << "moveExtendsSelection() after: " << moveExtendsSelection() << "\n";
qDebug() << "selections after: " << selections() << "\n";
qDebug() << "selectionStart after: " << selectionStart() << "\n";
qDebug() << "selectionEnd after: " << selectionEnd() << "\n";
The use case is:
No matter how a selection is started, <Shift><Arrow Key>, mouse, or numeric keypad, I should be able to determine a selection is in progress and have keypad navigation extend it.
Calling setSelectionMode() works only for pure keypad navigation.
Ultimately what I'm searching for are one or more signals coming from the C++ base class. Say . . .
#define SCI_SELECTION_STARTED some-value
#define SCI_SELECTION_CLEARED some-other-value
#define SCI_SELECTION_COPIED some-different-value
#define SCI_SELECTION_DELETED some-etc-value
CS_SIGNAL_1( Public, void selectionChanged( int statusChange, int anchor, int caret ) )
CS_SIGNAL_2( selectionChanged, statusChange, max, page )
I transmogrified the existing Qt code so in ScintillaEditBase.h you would be looking for this:
signals:
void horizontalScrolled(int value);
void verticalScrolled(int value);
void horizontalRangeChanged(int max, int page);
Perhaps the underlying Scintilla code is already emitting something via some message and I simply need to add support for signalling it out? I haven't dug that deep yet. I was hoping there was something obvious in the documentation I was missing.
Alternatively, what would be cool is to have all of the existing <Shift><Arrow Key> and mouse selection logic simply turn on moveExtendsSelection() but that would probably break a lot of behavior in the field. People might have gotten used to being able to clear a selection by hitting a navigation key without holding down a shift key.
Honestly, if Scintilla.h just had
#define SCN_SELECTION_STARTED 2100 // whatever
#define SCN_SELECTION_CLEARED 2101
#define SCN_SELECTION_COPIED 2102
#define SCN_SELECTION_DELETED 2103 // or cut if you prefer
and it came to the base class in an SCNotification() so it could be signaled out, I don't need any other information. I don't see any #define in Scintilla.h that leads me to believe the selection begin/end are communicated to the consumer.
What is happening here is a collision of historic UI practices and a tiny bit of an oddity in the widget itself. Older editor interfaces (pre-PC and mouse) were all mark then move. Selection started when you dropped the mark and any navigation method in any direction adjusted the selection. Scintilla seems to have that with setSelectionMode().
This doesn't play well with the mouse and <Shift> selection methods. Actually these two methods don't really play well with each other.
Begin a selection with a mouse then switch to <Shift> and arrow key. Selection will adjust properly.
Begin a selection with <Shift> arrow and try to extend with mouse. Selection clears instantly.
Begin a selection with setSelectionMode() and navigate a bit via the keypad. Navigation by arrow keys and Page Up/Down adjust the size of the selection. Mouse click clears selection instantly.
Begin selection with <Shift> arrow key and select some text. Hit the keypad period key to call setSelectionMode(). Keypad navigation will now adjust select range. Mouse click clears selection instantly.
I don't know. Let me mull it over a while. With previous versions of this editor using just the QPlainTextEdit of CopperSpice I was able to keep this in sync. (Not well though as two different entities were trying to keep track of selection.)
Maybe I just need to check __both__ moveExtendsSelection() and for a difference between selectionStart() and selectionEnd()? That would be relying on the editor widget keeping the end set to the start when a selection wasn't active. I seem to remember reading that in the doc.
Sorry for the long post to those who don't like to read. This is how my thought process works. I write it all down to help it turn the gears.