MARGINCLICK notification occurs on button press instead of release

29 views
Skip to first unread message

John Vella

unread,
Apr 12, 2012, 2:08:22 PM4/12/12
to scintilla...@googlegroups.com
I'm wondering if I'm not setting things up correctly to deal with "clicks" in my margin. And by "click" I mean the button1 press/release. I want to implement an action when the user clicks on a line's margin(in this case toggling the presence of a bookmark). However, if the user does a button press on one line, then drags the mouse and releases over a different line, I don't want to do anything.

What I'm seeing is the call to Editor::ButtonDown ends up calling NotifyMarginClick, which explains why I'm receiving that notification on the B1 press event. I'm surprised by this as I would have thought a "click" would be interpreted as having the B1 release occur over the same line as where the B1 press happened.

Is there a step here that I'm missing? Is there a technique I should use to get the behavior I want?

Neil Hodgson

unread,
Apr 12, 2012, 6:28:57 PM4/12/12
to scintilla...@googlegroups.com
John Vella:

> What I'm seeing is the call to Editor::ButtonDown ends up calling
> NotifyMarginClick, which explains why I'm receiving that notification on the
> B1 press event. I'm surprised by this as I would have thought a "click"
> would be interpreted as having the B1 release occur over the same line as
> where the B1 press happened.

The use case this was implemented for was for the fold margin for
folding and unfolding text. Other applications with folding, like
Visual Studio, perform folding on button down. Tree controls also
expand and contract branches on button down.

Neil

Brian Griffin

unread,
Apr 12, 2012, 7:57:07 PM4/12/12
to scintilla...@googlegroups.com

Action on button down is generally considered bad form. Actions should be triggered on button up as this will give the user the opportunity to "abort" the action by moving out of scope. If some places react on button down and other react on button up, it creates confusion and hesitance in the user's mind since they're not sure what the risk is in the mouse button action before taking it. Always waiting for the up event will allow for an "out" if the action is not desired.

Reacting on button down also limits the notion of having draggable objects in the margin and allowing direct manipulation of the objects.


"Mouse-up event == Click"

Reference: "Use User-Centric Terminology" (https://developer.apple.com/library/mac/#documentation/UserExperience/Conceptual/AppleHIGuidelines/UEGuidelines/UEGuidelines.html#//apple_ref/doc/uid/TP40002720-TPXREF101)


"If users move the pointer outside the open menu without releasing the mouse button, the current value remains active. An exploratory press in the menu to see what’s available doesn’t select a new value."

Reference: "Pop-up Menu Usage" (https://developer.apple.com/library/mac/#documentation/UserExperience/Conceptual/AppleHIGuidelines/Controls/Controls.html#//apple_ref/doc/uid/TP30000359-TP6)


-Brian

Reply all
Reply to author
Forward
0 new messages