Click handler for go.Panel not invoked with Ctrl key pressed

I have an interesting diagram implementation that has nodes with expandable sections that overlays their respective nodes.

In the expansion area there is repeating sections each with a click handler applied. All clicks are handled, even clicks with the shift & alt keys held down. The problem is that the ctrl key will see the event handler not triggered at all.

I’m planning functionality that relies on a ctrl+click interaction, but with this quirk, it would not be possible.

See the following CodePen for an example:

Any guidance would be appreciated

Hmmm. This seems to solve the immediate problem:

      itemTemplate: $(go.Panel, "Auto",
          // so that this Panel handles all mouse-down-move-up & cancel events,
          // rather than other Tools, set GraphObject.isActionable to true
          isActionable: true,
          name: "item",
          click: (e, obj) => {
            e.handled = true;  // you might want this too
            . . .

But I don’t think this is a great solution for you, because it will prevent starting the TextEditingTool unless you handle that yourself. I can look into why you’re not getting the click event when control is pressed.

Unrelated comments:

  • You probably want to set InputEvent.handled; otherwise the click event passes through to the underlying Node and its selection is changed. But maybe you want that.

  • There’s a Binding error:

Binding error: TypeError: n.items is undefined setting target property "height" on Shape(RoundedRectangle)#459 with conversion function: (n) => n.items.length * 24 + 2
  • There’s no point in setting Diagram.layout to an instance of a plain Layout – that’s its default value.

  • There’s no point in wrapping a single element in an “Auto” (or “Spot”) Panel, like your TextBlock. Unless maybe your code is a simplification of your actual Node template…

Thanks Walter, the ‘isActionable’ & InputEvent.handled property sorted it out.

As for your other comments, I cleaned up the example, and your suspicion is correct, the example is a simplification of my actual application.

The pen ( will remain for anyone to learn from.

I tried to reproduce the bug but was unable to. But I did figure out why it’s behaving that way for you.

A control-click is normally used to toggle the Part.isSelected property. (Shift-click makes sure the Part is selected, whether or not it had been before the click.)

But your code removes that overlaid panel when the node loses selection. When the control-click occurs, it unselects the node, which causes that panel to become not-visible. Then when the code to handle clicks is called (including double clicks and context clicks) that panel isn’t there any more because it is invisible, so it can’t receive any input events.

So there’s no bug handling input events.