`Tool#onCancel` does not fire when a tool is reselected by command

[DanRathbun]

SketchUp Ruby API Issue

The #onCancel callback for Ruby tools does not fire when a tool is reselected by command.

The callback is supposed to be called and return 1.

But I can never get this to happen, whether I use the same tool instance for a model or re-instantiate the tool object for each command call.

We often want to use the onCancel callback to set state or persistent data. We cannot do this easily if this reason was short-circuited because it was thought that it did not matter as the tool would be or should be reactivated at it's initial state.

Is there any indication in the code comments when this stopped working and why?

---

RELATED ISSUES

• Issue 552 : Define constants for Tool onCancel reasons

• Issue 458 : onCancel - No indication of Undo versus Redo

• Issue 176 : Undocumented behaviour of tool event return value

[Fredosixx]

It has never worked.... onCancel always returns 0 (Escape) or 2 (Undo or Redo).

Personally, the reactivation of the same tool should be managed by the tool launcher. Sometimes, you precisely want that you exit, sometimes you want to use another tool (like ThruPaint, which launches the regular Paint Bucket Tool), sometimes, you just want to ignore.

What has also been requested is to have onCancel differentiate between Undo and Redo (#458).

[DanRathbun]

@Fredosixx Personally, the reactivation of the same tool should be managed by the tool launcher.

(1) Often the launcher is just a command proc, that has activated an instance of the tool and returned. The only current callback-like mechanisn in the UI::Command interface is the menu validation proc.

(2) The onCancel callback is already documented (therefore forming an API contract) to return 1 upon a reselect.

(3) This callback is a before event callback (as yourself noted) and it would be desirable to know whether the user reselected the tool which indicates most likely that the user wishes to reset the tool to initial state. It is possible that some state or data would need to be passed (or made persistent somehow) between tool cycles, and so this callback affords the opportunity to set some flag at the very least in some "launcher" or controlling module so that the next tool cycle / instance (whatever) knows that it was a recycle from a past tool cycle.

---

@Fredosixx What has also been requested is to have onCancel differentiate between Undo and Redo (#458).

I noted this in the RELATED section of the FR report (above.)

[thomthom]

Hm... I think I've seen onCancel trigger when reactivated like that. But not sure when. I usually handle onCancel without checking reason or only checking for Escape.

[sketchup[bot]]

Logged as: SKEXT-3760