Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
DanRathbun opened this issue Jul 2, 2023 · 4 comments
Open

Comments

@DanRathbun
Copy link

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

@Fredosixx
Copy link

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
Copy link
Author

@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
Copy link
Member

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
Copy link

sketchup bot commented Jul 17, 2023

Logged as: SKEXT-3760

@sketchup sketchup bot added the logged label Jul 17, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants