We had a discussion about mouse messages and events, and we disagreed, as usual
Pressing an mouse button (in detail the left one) can mean many things. Most obvious is the begin of a sequence of clicks, where Lazarus for some reason supports up to quadruple clicks. If only one event shall be signaled, then the handling of the mouse up and down messages must be delayed, until the timeout or maximum sequence number is reached. When a mouse down also can start dragging, processing can be inlined into that delayed handling. As the word says, "drag" means *moving* something, so that an automatic dragging operation always should start only after an significant move of the mouse. When the dragging threshold was not reached on mouse up, no dragging actions or messages should have occured, and the click processing should continue.
Such processing would eliminate the long standing note on WM_MOUSEDOWN in TControl.WndProc, where Delphi stops further processing after starting the dragmanager, and the LCL continues to process the message. IMO it would be much more transparent to stop handling of the message, and to leave it to the drag manager to delay further processing, until it's clear whether a drag should start, or normal click handling should occur. Or the drag manager could be invoked only in that place, where a mouse move would break a sequence of clicks. This latter solution would concentrate all decisions in one place, so that conflicts with already started dragging operations can no more occur. The TControl.IsDragging method could be based on a flag in the control's state, that steers the handling of all mouse messages. The control states then become:
IDLE <down ---> DOWN /move ---> DRAGGING <up ---> DROPPED
\ up ---> 1CLICK - - - > 4CLICK
Then also the dragging threshold could reflect the system threshold, not an application specific (and consequently unexpected) value.
No comments:
Post a Comment