DragSelectingTool influence on PanningTool

Hello,

I have a question, which might be related to something that I have incorrectly configured in my diagram, because I cannot replicate the same behavior with the samples. What could possibly make PanningTool include DragSelectingTool.box into computation when panning the view?

I have this strange behavior, which I want to get rid off. When drag selecting a node and then releasing the mouse button, we can see that panning includes the box part of DragSelectingTool into calculations, because we cannot pan the view like in the initial conditions. Once you select and deselect a node by clicking on the diagram background, then you can pan the view like expected.

https://we.tl/t-7we0ahO6Wr

The box is taken from Real Time Drag Selecting Tool Sample and I use it in the diagram.
I have tried to use default DragSelectingTool, but it yields the same behavior.

PanningTool has no modifications except for canStart where I check for right mouse button click instead of left. Changing this to default still yields the same unexpected behavior.

Diagram uses LayeredSubGraphLayout, but I have tried to change it to default Layout and TreeLayout, still it yields the same behavior.

I came into conclusion, that PanningTool incorrectly calculates the position by including box or DragSelectingTool or DragSelectingTool fails to remove it’s box on doDeactivate.

What could possibly cause this issue?

Kind regards,
Ovidijus

It looks as if the box Part is still in the “Tool” Layer, and thus in the document bounds, even though it shouldn’t be in any Layer at all when not visible.

If you try using both a default DragSelectingTool and a default PanningTool, does the problem happen?

Are there any console messages? It might help to use go-debug.js.

Using default DragSelectingTool makes it harder to replicate the described issue. I can only see somewhat similar behavior, if I am trying to auto scroll while using DragSelectingTool on the edge of Diagram.

PanningTool does not influence this issue, because with default and the one that I’m using I see the same behavior and logically thinking it should not influence anything because the only place changed was canStart method.

No console messages unfortunately apart from unrelated one:

image
.

Thanks for info on PanningTool changes – I agree it shouldn’t matter. What about other tool changes?

I flat out use RealTimeDragSelectingTool from that sample, which I previously attached.
I also use GuidedDraggingTool which is also straight from the guided dragging sample.

I also have TextEditingTool, LinkingTool and RelinkingTool modified, but they should not influence this issue.

Apart from these I don’t override any other tools.

I’ll do some experiments.

1 Like

I’m unable to reproduce the problem. My code:

  <script src="../release/go-debug.js"></script>
  <script src="../extensions/GuidedDraggingTool.js"></script>
  <script src="../extensions/RealTimeDragSelectingTool.js"></script>
  <script id="code">
const $ = go.GraphObject.make;

const myDiagram =
  $(go.Diagram, "myDiagramDiv",
    {
      draggingTool: new GuidedDraggingTool(),
      dragSelectingTool:
        $(RealtimeDragSelectingTool,
          {
            isPartialInclusion: true,
            // delay: 50,
            box: $(go.Part,  // replace the magenta box with a red one
              { layerName: "Tool", selectable: false },
              $(go.Shape,
                {
                  name: "SHAPE", fill: "rgba(255,0,0,0.1)",
                  stroke: "red", strokeWidth: 2
                }))
          }
        ),
. . . the rest doesn't matter . . .

I’ve spent quite some time on this issue now…

I’ve looked into “Tool” Layer after stopTool method and there were no Parts.

Somehow computeBounds of Diagram was still including box in documentBounds even if it’s invisible.

I’ve looked into how Diagram.computeBounds works and found, that parts which have isInDocumentBounds set to false are not included. So I have set this to false on RealTimeDragSelectingTool.box Part and the issue is fixed now, box is still visible and Tool works as expected.

But this does not feel like the right solution at the moment. I’ll mark it anyways.