Multi-selection and SCN_UPDATEUI notification

74 views
Skip to first unread message

John Ehresman

unread,
Oct 29, 2015, 11:27:23 AM10/29/15
to scintilla...@googlegroups.com
It looks like SCN_UPDATEUI notifications are not sent when selections
are set via SCI_SETSELECTIONN* messages. I think this notification
should be sent, at least when the main selection changes; I have code
that uses these messages even when there's only a single selection and
was surprised by the difference in behavior.

A workaround seems to be to call SCI_SWAPMAINANCHORCARET twice; I
couldn't figure out another way to trigger a call to the internal
InvalidateSelection() method.

John

Neil Hodgson

unread,
Oct 29, 2015, 5:47:16 PM10/29/15
to scintilla...@googlegroups.com
John Ehresman:

> It looks like SCN_UPDATEUI notifications are not sent when selections are set via SCI_SETSELECTIONN* messages. I think this notification should be sent, at least when the main selection changes; I have code that uses these messages even when there's only a single selection and was surprised by the difference in behaviour.

The reasoning here is that the notification is used to tell the application about events it has no direct control over such as the user pressing the right arrow key. When the application calls SCI_SETSELECTIONN* then it can just call its own update handler.

If someone wants to add SCN_UPDATEUI to selection changing calls then that would be OK.

Neil

John Ehresman

unread,
Nov 13, 2015, 10:24:41 AM11/13/15
to scintilla...@googlegroups.com
On 10/29/15 5:47 PM, Neil Hodgson wrote:
> The reasoning here is that the notification is used to tell the application about events it has no direct control over such as the user pressing the right arrow key. When the application calls SCI_SETSELECTIONN* then it can just call its own update handler.
>
> If someone wants to add SCN_UPDATEUI to selection changing calls then that would be OK.

I think I'd like to see SCN_UPDATEUI sent whenever any selection changes
so I can avoid problems when I add a handler but forget to go back and
change older code. I've attached a diff to add the update messages when
the SETSELECTIONN messages. I understand if you don't want to make this
change and will work around it -- probably by essentially subclassing
the access class.

I noticed in some cases the SC_UPDATE_SELECTION bit is not set
consistently -- it's set on a deletion but not when text is inserted for
example. I suspect most code just processes the UPDATEUI message without
checking the modified bits.

I also noticed that the updateUi signal on qt ScintillaEditBase class
does not pass along the modified field. I've changed this locally and
can send the (small) patch, but I don't know if it's worth changing the
ABI for this.

Thanks,

John


sel-updates.diff

Neil Hodgson

unread,
Nov 14, 2015, 8:26:47 PM11/14/15
to scintilla...@googlegroups.com
John Ehresman:

> I think I'd like to see SCN_UPDATEUI sent whenever any selection changes so I can avoid problems when I add a handler but forget to go back and change older code. I've attached a diff to add the update messages when the SETSELECTIONN messages.

OK. Committed.
https://sourceforge.net/p/scintilla/code/ci/1bb3e86c576b0334ccbd7ac2fd69c4a48909e41f/

> I noticed in some cases the SC_UPDATE_SELECTION bit is not set consistently -- it's set on a deletion but not when text is inserted for example. I suspect most code just processes the UPDATEUI message without checking the modified bits.

I think the reasoning was that SC_UPDATE_CONTENT implies that the selection changed. SC_UPDATE_SELECTION indicates just that selection changed. The application may need to update fewer elements when the selection changes than when the text changes.

> I also noticed that the updateUi signal on qt ScintillaEditBase class does not pass along the modified field. I've changed this locally and can send the (small) patch, but I don't know if it's worth changing the ABI for this.

This is the cost of more explicit typing for Qt. Its up to you and the other users of the Qt platform to decide what is a reasonable approach to compatibility here.

Neil

John Ehresman

unread,
Nov 17, 2015, 5:18:40 PM11/17/15
to scintilla...@googlegroups.com
On 11/14/15 8:26 PM, Neil Hodgson wrote:
>> I think I'd like to see SCN_UPDATEUI sent whenever any selection changes so I can avoid problems when I add a handler but forget to go back and change older code. I've attached a diff to add the update messages when the SETSELECTIONN messages.
>
> OK. Committed.
> https://sourceforge.net/p/scintilla/code/ci/1bb3e86c576b0334ccbd7ac2fd69c4a48909e41f/

Thanks.

>> I noticed in some cases the SC_UPDATE_SELECTION bit is not set consistently -- it's set on a deletion but not when text is inserted for example. I suspect most code just processes the UPDATEUI message without checking the modified bits.
>
> I think the reasoning was that SC_UPDATE_CONTENT implies that the selection changed. SC_UPDATE_SELECTION indicates just that selection changed. The application may need to update fewer elements when the selection changes than when the text changes.

It might be worth changing it for consistency sake, but it's a minor point.

>> I also noticed that the updateUi signal on qt ScintillaEditBase class does not pass along the modified field. I've changed this locally and can send the (small) patch, but I don't know if it's worth changing the ABI for this.
>
> This is the cost of more explicit typing for Qt. Its up to you and the other users of the Qt platform to decide what is a reasonable approach to compatibility here.

I think it's fine to leave it as is for now. I've reverted the change
locally for now because our code does not need the modified field.

John

Reply all
Reply to author
Forward
0 new messages