Problematic click handling


I noticed a problem with the way mouse clicks are handled. It is especially annoying when collapsing/expanding a SubGraph by clicking on the collapse/expand handle.
Some clicks are not being handled/raised if the mouse if slightly moved during the click. In otherwords, any mouse movement while clicking starts a drag instead of a click.
In windows there is a standard drag size:
Size dragSize = SystemInformation.DragSize ;
The drag box should be calculated in MouseUp and compared to in MouseMove. Is the standard drag box logic handled in the current implementation of GoDiagram?
If not can it be fixed?
Yuval Naveh


I think you can customize this by overriding GoToolDragging.CanStart(). You’ll need to check if the distance from FirstInput.ViewPoint to LastInput.ViewPoint is within the range you want (such as SystemInformation.DragSize), and if so, return false so that the dragging tool isn’t started.
Maybe we should make this a property on this tool class, with a default value that is SystemInformation.DragSize.
By the way, GoToolRubberBanding already observes SystemInformation.DragSize, to allow a tiny drag in the background to appear as if it were a click in the background.


Thanks I implemented it as you suggested.
It helps a bit, but some clicks are still getting lost…
The expand/collapse handle does not behave like a true windows button (which it should mimic).
Have no idea why.


We have been wrestling with a related problem. Perhaps your problem and ours are unrelated, but if you were to investigate and determine that your symptoms are indeed the same, it would help us out considerably.
What we find is that frequently, a mouse down event is not paired with a corresponding OnMouseUp, although the WM_LBUTTONUP is pumped as expected.
We notice this in another managed windows app (Crownwood libraries) which does significant mouse move handling, and since we have the source, we verified the situation as above. We also notice this in GoDiagram, but not having the source, we can’t verify the condition as the same.
We are investigating whether this is related to excessive handling of mouse move events (since no PeekMessage is available), but this is merely a guess at this point.