Using SC_UPDATE_SELECTION instead of SCN_POSCHANGED()

[johnsonj]

Changeset:
6668 (3f20bac89b30) Bug [#2006]. State SCN_UPDATEUI is an indication that change may have occurred …

SCN_POSCHANGED() was removed.
So I have used this code instead.

case SCN_UPDATEUI:
    if (scn.updated & SC_UPDATE_SELECTION) // instead of SCN_POSCHANGED()
    updateMicroFocus();

Selection has been changed.
I see that a normal caret always has 0-length selection.
Caret moves with 0-length selection, when caret position equals anchor one.

Now if Document says "Selection may have been changed.",
How can I detect SCN_POSCHANGED()?

[Neil Hodgson]

johnsonj:

> Changeset:
> 6668 (3f20bac89b30) Bug [#2006]. State SCN_UPDATEUI is an indication that change may have occurred …
>

> Now if Document says "Selection may have been changed.",
> How can I detect SCN_POSCHANGED()?

If you need to tell that the selection truly changed then store the selection when SCN_UPDATEUI is received and compare it to the previous value.

The change in the documentation is saying that you may receive a SCN_UPDATEUI when there has not been an actual change in the selection. Such events may occur because the mouse is moving slightly in pixels but not in characters or when timer ticks are being used to perform automatic scrolling. These null SCN_UPDATEUI events will not be common in normal usage.

The other side of this is that not every change in selection causes one SCN_UPDATEUI. That is because SCN_UPDATEUI are sent on idle or in the painting code. If the user is dragging the mouse or pressing keys rapidly then there may have been multiple changes to the selection between SCN_UPDATEUI events. This avoids slow-downs, jerky mouse movement, and queued input continuing after the user stops. When any change is made to the selection then there will eventually be a SCN_UPDATEUI although that may be shared with other selection changes.

Neil