Unexpected Selection

57 views
Skip to first unread message

gbeene

unread,
Aug 15, 2010, 11:22:16 PM8/15/10
to scintilla-interest
When the left mouse is pressed in Scintilla, my app does some
processing, including changing the content of the Scintilla control if
the mouse is pressed over a hotspot.

When I release the mouse, portions of the Scintilla text become
selected, even though I've not issued any commands to select that text
range. I tried forcing no selection, but the selection still occurs.

The unwanted selection seems to end at the screen position where I
release the mouse, whereas the start of the selection seems at random.

Any suggestions on what is causing this / how to prevent the unwanted
selection?





Neil Hodgson

unread,
Aug 16, 2010, 3:41:25 AM8/16/10
to scintilla...@googlegroups.com
gbeene:

> When I release the mouse, portions of the Scintilla text become
> selected, even though I've not issued any commands to select that text
> range.  I tried forcing no selection, but the selection still occurs.

If you are intercepting the mouse down then you probably need to
intercept the mouse up.

Neil

gbeene

unread,
Aug 16, 2010, 9:46:52 AM8/16/10
to scintilla-interest
Sorry, I left the wrong impression.

My processing is in the SCN_HOTSPOTCLICK event. I noticed that the
code in that event is executed after I press the mouse, then when I
release the mouse the unexpected selection takes place.

Jeff Pohlmeyer

unread,
Aug 16, 2010, 10:14:48 AM8/16/10
to scintilla...@googlegroups.com
On Mon, Aug 16, 2010 at 8:46 AM, gbeene wrote:

> My processing is in the SCN_HOTSPOTCLICK event. I noticed that the
> code in that event is executed after I press the mouse, then when I
> release the mouse the unexpected selection takes place.


Seems like I ran into something similar to this with FXiTe's help system,
but the problem was that jumping to a different part of the document when
a hotspot was clicked caused an (unwanted) selection to be created.

The solution for me was to move the "problem" code into a separate mouse-up
function that would run conditionally, depending on the status of a flag that
was set by the SCN_HOTSPOTCLICK event.

- Jeff

gbeene

unread,
Aug 16, 2010, 11:04:54 AM8/16/10
to scintilla-interest
Jeff, thanks for the info. What you describe is definitely similar to
what I'm seeing.

I wound up using Sci_HideSelection before doing any processing in the
SCN_HOTSPOTCLICK event. Afterwords, in the WM_LButtonUp event, I
restored the selection and used Sci_SetSel to remove the unwanted
selection. Like you, I use a flag in the mouseup code so that it only
runs when a hotspot has been clicked.

Interestingly, I had to use PostMessage, not SendMessage, or else the
Sci_SetSel didn't take effect. That would seem to indicate there is
still some other event that would be a better place to intercept
whatever is causing the unwanted selection, but I'm not sure what it
is.

The Sci_HideSelection was necessary because the unwanted selection
flashed on the screen until the PostMessage takes effect.

So what I works now, but there's still a piece of the puzzle that's
not clear.

> The solution for me was to move the "problem" code into a separate mouse-up
> function that would run conditionally, depending on the status of a flag that
> was set by the SCN_HOTSPOTCLICK event.
>
> - Jeff

Regards,
Gary

Neil Hodgson

unread,
Aug 16, 2010, 5:34:24 PM8/16/10
to scintilla...@googlegroups.com
From Scintilla's point of view a hotspot click is no different from
any other click (apart from sending SCN_HOTSPOTCLICK) and all other
processing such as selection occurs.

Neil

Simon Steele

unread,
Aug 16, 2010, 10:07:43 AM8/16/10
to scintilla...@googlegroups.com
Hi,

When handling SCN_HOTSPOTCLICK I post a message to my window to handle the event after the Scintilla notification rather than inline. I seem to remember doing this to avoid exactly this problem. I noticed it when I was switching views on a hotspot click, and the application window layout changing in the middle of a mouse-down call to Scintilla seemed to be the cause of the false-selection.

Hope that helps,

Simon.


--
You received this message because you are subscribed to the Google Groups "scintilla-interest" group.
To post to this group, send email to scintilla...@googlegroups.com.
To unsubscribe from this group, send email to scintilla-inter...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/scintilla-interest?hl=en.


gbeene

unread,
Aug 16, 2010, 11:26:07 PM8/16/10
to scintilla-interest
Hi Simon,

Thanks for the information. I'll give it a try by using a PostMessage
(in the Scintilla event) to a user-defined message that contains the
processing code and see how that works.

David

unread,
Aug 17, 2010, 12:18:37 AM8/17/10
to scintilla...@googlegroups.com
On 16 August 2010 13:22, gbeene <gbe...@airmail.net> wrote:
>
> When I release the mouse, portions of the Scintilla text become
> selected, even though I've not issued any commands to select that text
> range.  I tried forcing no selection, but the selection still occurs.

For what its worth, I have several times seen a possibly similar bug
affect the output pane of the current version of SciTE. I will try to
pay more attention next time it occurs to see if I can define the
steps to reproduce it.

ian.g...@gmail.com

unread,
Jan 6, 2015, 9:28:16 AM1/6/15
to scintilla...@googlegroups.com
This is an old thread, but the 'problem' still exists (and just bit me). The following explanation might help:

Releasing the mouse button results in a call to Editor::ButtonUp in the Scintilla code. This does a bit of initial processing, and then invokes SCN_HOTSPOTRELEASECLICK. This is where we do something in response to the user clicking on the hot spot. (In my case it was to make the insertion point jump to the definition of the variable that was clicked.) After the SCN_HOTSPOTRELEASECLICK handler returns, Editor::ButtonUp continues processing. In the ordinary case we're concerned with here, it then re-establishes the selection based on the current insertion point, the assumption being that this is unchanged from when the button was clicked.

The problem occurs when the SCN_HOTSPOTRELEASECLICK handler changes the current insertion point. In this case it has the unfortunate effect of creating a selection between the point where the mouse was clicked and the point that the handler moved the insertion point to.

I don't think this is a bug in Scintilla as such, and avoiding the problem without causing other unintended side-effects might be tricky.

The workaround is for the SCN_HOTSPOTRELEASECLICK handler not to modify the insertion point position, but instead to queue a message to cause this to happen later, once Editor::ButtonUp has finished. On Windows you can PostMessage a custom message to yourself to achieve this.

I've created a bug to update the documentation: https://sourceforge.net/p/scintilla/bugs/1679/
Reply all
Reply to author
Forward
0 new messages