draggingTool doCancel does not release the mouse

I’m using draggingTool to start the drag, but because the draggable element must be dropped outside the canvas , I’m trying to cancel the drag and to implement a custom html dragging. The thing is that in this process events hang and are not released until I do another little drag, no matter on which part of the screen (on or away from the canvas). I tried to replace draggingTool without any success. I could not call dragging tool constructor. Other idea that fails was to discard draggingTool and to find a replacement. I looked for a mouse down event that will tell me on which element of gojs is happened, but I could not find that either.

let tool = diagram.toolManager.draggingTool;
// tool.doDeactivate();

Your situation involves a drag-and-drop from one Diagram to another one, yes?

If so, that means there are two Diagrams and thus two DraggingTools involved. I suspect you are trying to cancel the operation of the wrong one – the one at the target diagram.

But even so, I think that trying to cancel during a drag is the wrong thing to do. Say there are three diagrams in your app and the user passes the mouse/finger over a second diagram on the way to the third diagram. If you successfully canceled the whole drag-and-drop operation just because you thought it was a bad idea while over the second diagram, that would prevent the user from dragging to the third diagram.

First , thank you for the reply! Overall I’m stuck with this problem and began thinking for radical solutions like recreating the diagram. This means that it will most probably flicker but it’s very nasty in the case it is now.

My case obviously was not explained very clear, so here is another try: I want to copy a part of the diagram to my custom html component mimicking drag-drop copy operation. So on drag I want to take the coordinates of the diagram’s part only. After that I draw a similar looking div on top of the diagram draggable part and start a custom drag and drop, that does not involve diagram dragging at all. So in reality I move my div but I need to cancel the actual dragging of the diagram part. So I only use the diagram dragging to find the draggable part and to get its bounds. After that It’s completely different mechanism that cares for the actual dragging and dropping.

let part = tool.findDraggablePart();
let nodeBounds = part.actualBounds;
let nodeData = part.data;
let canvasPosition = $("#diagram").offset();
let top = canvasPosition.top + (nodeBounds.top - diagram.position.y) * diagram.scale;
let left = canvasPosition.left + (nodeBounds.left - diagram.position.x) * diagram.scale;
let width = nodeBounds.width;
let height = nodeBounds.height;

With all of the above values I can style and position my own div on top and continue the move with it.

Much easier would be a mousedown event with some delay on which I can take all those values, but I don’t see an appropriate tool with mousedown enabled. MouseUp and click are too late because I can’t imitate a real drag and drop. You mouse down, move the mouse and release the button on the place you want to drop.

Ah, OK, that makes sense.

I think overriding DraggingTool.doActivate might make the most sense for you. The standard behavior of DraggingTool.doActivate calls Tool.standardMouseSelect, sets Tool.isActive to true remembers some state, calls DraggingTool.computeEffectiveCollection (to figure out what to drag, which may include many Parts), remembers the result of that call as DraggingTool.draggedParts, starts a transaction, captures the mouse, and actually starts the dragging operation.

I haven’t tried this, but perhaps you could do something like override in the initialization of your Diagram:

    . . .,
    "draggingTool.doActivate": function() {
        if (... this is not supposed to be a regular drag ...) {
            ... do your own drag ...
        } else {

However, I’m wondering if that might not be too early. For example you might want to decide to cancel the regular drag only when the mouse leaves the viewport. I think that would still work OK, because calling doCancel will call stopTool which will call doDeactivate which stops capturing the mouse.

1 Like

Works like a charm! Thank you!