> 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
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