Don't construct this directly -- this is an abstract class.
This read-only property returns the Diagram that owns this tool and for which this tool is handling input events.
Gets or sets whether this tool is started and is actively doing something.
You can set this to true after your tool is started (i.e. when it is the Diagram.currentTool and doStart had been called), but when it is not yet in a state that it is actually "doing" something, because it is waiting for the right circumstances. This is typically only important when the tool is used in a modal fashion.
The default value is false. This is normally set by doActivate and doDeactivate.
Gets or sets whether this tool can be started by a mouse event.
Set this to false to prevent canStart from returning true. Setting this property to false should prevent this tool from being used in a mode-less fashion by the ToolManager with a mouse down/move/up event. However, even when this property is false, this tool can still be used in a modal fashion: it can still be started by explicitly setting the Diagram.currentTool property to this tool.
The default value is true.
Gets or sets the name of this tool. The default name is an empty string, but the constructor for each instance of a subclass of Tool will initialize it appropriately. For example, the name of the DragSelectingTool is "DragSelecting".
This name is sometimes used by tools that use Adornments as the Part.category for their Adornments. It is also sometimes used by tools that conduct transactions as the transaction name.
Gets or sets the name of the transaction to be committed by stopTransaction
If null, the transaction will be rolled back.
If this is non-null at the time of a call to stopTransaction, it calls Diagram.commitTransaction with this transaction name; if this is null at that time, it calls Diagram.rollbackTransaction.
The default value is null; startTransaction will also set this to null. Because a value of null when stopTransaction is called will rollback the transaction, it is important that your code sets this property to a non-null value when it thinks it has succeeded.
This property exists so that no matter what execution path occurs to end the usage of a tool, any ongoing transaction can be properly committed or rolled-back. Many tools call startTransaction and stopTransaction; thus they set this property for their transaction to be committed. doCancel also sets this property to null.
This predicate is used by the ToolManager to decide if this tool can be started mode-lessly by mouse and touch events. Implementations of this method can look at Diagram.lastInput to get the mouse event and input state.
By default this method returns isEnabled. This method may be overridden. Please read the Introduction page on Extensions for how to override methods and how to call this base method.
true if isEnabled is true and if the Diagram.toolManager can make this tool the Diagram.currentTool and then call the doStart method.
Called by ToolManager.doMouseDown and ToolManager.doMouseMove, this method determines whether or not to allow pinch zooming from a multi-touch event. By default this predicate just returns true. This method may be overridden. Please read the Introduction page on Extensions for how to override methods and how to call this base method.
This is called to cancel any running "WaitAfter" timer.
This is called when a tool is stopped.
This method is rarely overridden. Please read the Introduction page on Extensions for how to override methods and how to call this base method.
The Diagram calls this method after setting Diagram.currentTool, to make the new tool active. This should set isActive to true. Overrides of this method might call startTransaction, if this tool's activity involves modification of the model. Implementations of this method can look at Diagram.lastInput to get the mouse event and input state.
You should call this method only after setting Diagram.currentTool to the Tool that you want to activate.
By default this only sets isActive to true. This method may be overridden. Please read the Introduction page on Extensions for how to override methods and how to call this base method.
If you override this method, it is commonplace to also override doDeactivate to clean up whatever you set up in this method.
The diagram will call this method when the user wishes to cancel the current tool's operation. Typically this is called when the user hits the ESCAPE key. This should restore the original state of what was modified by this tool, and then it should call stopTool. This method is not responsible for cleaning up any side-effects that should be performed by doDeactivate and/or doStop, which will always be called whether the tool stops normally or abnormally.
By default this method just sets transactionResult to null and calls stopTool. You will want to override this method even in tools that call startTransaction and stopTransaction, because the UndoManager might not be enabled. This method may be overridden. Please read the Introduction page on Extensions for how to override methods and how to call this base method.
The Diagram calls this method on the old tool when Diagram.currentTool is set to a new tool. This needs to set isActive to false. Overrides of this method might call stopTransaction, if this tool's activity involves modification of the model.
You should have no reason to call this method, because it is automatically called by the Diagram.currentTool property setter on the old tool.
By default this only sets isActive to false. This method may be overridden. Please read the Introduction page on Extensions for how to override methods and how to call this base method.
It is commonplace to override this method in order to clean up whatever you have set up in an override of doActivate.
The diagram will call this method upon a key down event. By default this just calls doCancel if the key is the ESCAPE key. Implementations of this method can look at Diagram.lastInput to get the key.
This method may be overridden. Please read the Introduction page on Extensions for how to override methods and how to call this base method.
The diagram will call this method upon a key up event. Implementations of this method can look at Diagram.lastInput to get the key.
By default this method does nothing. This method may be overridden. Please read the Introduction page on Extensions for how to override methods and how to call this base method.
The diagram will call this method upon a mouse down event. This is normally overridden for mouse-down tools; it is not called for mouse-move or mouse-up tools. However it may also be called when the tool is run in a modal fashion, when code explicitly sets the diagram's Diagram.currentTool. Implementations of this method can look at Diagram.lastInput to get the mouse event and input state.
By default this method checks isActive; if that is false it calls canStart. If that in turn is true, this calls doActivate. This method may be overridden. Please read the Introduction page on Extensions for how to override methods and how to call this base method.
The diagram will call this method upon a mouse move event. This is normally overridden for mouse-move tools; it is not called for mouse-up tools. However it may also be called when the tool is run in a modal fashion, when code explicitly sets the diagram's Diagram.currentTool. An override of this method usually does nothing when isActive is false. Implementations of this method can look at Diagram.lastInput to get the mouse event and input state.
By default this method does nothing. This method may be overridden. Please read the Introduction page on Extensions for how to override methods and how to call this base method.
The diagram will call this method upon a mouse up event. This is normally overridden for mouse-up tools. An override of this method usually does nothing when isActive is false, except for calling stopTool. Tools normally stop upon a mouse up, by calling stopTool. If you want to handle multiple mouse down-up gestures in one tool activation, you will need to override this method to only stop the tool when you want. Implementations of this method can look at Diagram.lastInput to get the mouse event and input state.
By default this method just calls stopTool. This method may be overridden. Please read the Introduction page on Extensions for how to override methods and how to call this base method.
The diagram will call this method as the mouse wheel is rotated. Implementations of this method can look at Diagram.lastInput to get the mouse event and input state.
By default this method does nothing. (But the ToolManager.doMouseWheel override will call Tool.standardMouseWheel.) This method may be overridden. Please read the Introduction page on Extensions for how to override methods and how to call this base method.
The Diagram calls this method when this tool becomes the current tool; you should not call this method. Tool implementations should perform their per-use initialization here, such as setting up internal data structures, or capturing the mouse. Implementations of this method can look at Diagram.lastInput to get the mouse event and input state.
You should not call this method -- only the Diagram.currentTool property setter should call this method.
By default this method does nothing. This method may be overridden. Please read the Introduction page on Extensions for how to override methods and how to call this base method.
If you override this method, it is commonplace to also override doStop to clean up whatever you set up in this method.
The Diagram calls this method when this tool stops being the current tool; you should not call this method. Tool implementations should perform their per-use cleanup here, such as releasing mouse capture.
You should not call this method -- only the Diagram.currentTool property setter should call this method. If you want to stop a tool unexpectedly, you should call doCancel. If your implementation of a tool wants to stop itself, you should call stopTool.
By default this method does nothing. This method may be overridden. Please read the Introduction page on Extensions for how to override methods and how to call this base method.
It is commonplace to override this method in order to clean up whatever you have set up in an override of doStart.
This is called a certain delay after a call to standardWaitAfter if there has not been any call to cancelWaitAfter. The ToolManager overrides this method in order to implement support for mouse-hover behavior and tooltips.
By default this does nothing. This method may be overridden. Please read the Introduction page on Extensions for how to override methods and how to call this base method.
The event that caused standardWaitAfter.
This convenience function finds the front-most GraphObject that is at a given point and that is an element of an Adornment that is of a given category. The tool handle must be an immediate element of the Adornment, not a GraphObject that is nested within Panels within the Adornment.
This method is very infrequently overridden. Please read the Introduction page on Extensions for how to override methods and how to call this base method.
a Point in document coordinates.
the required Part.category of the Adornment.
Return true when the last mouse point is far enough away from the first mouse down point to constitute a drag operation instead of just a potential click.
This uses the value of ToolManager.dragSize. On touch devices the value is automatically increased to accommodate the unavoidable movement of fingers.
This method may be overridden. Please read the Introduction page on Extensions for how to override methods and how to call this base method.
Point in view coordinates, defaults to Diagram.firstInput's InputEvent.viewPoint.
Point in view coordinates, defaults to Diagram.lastInput's InputEvent.viewPoint.
Implement the standard behavior for mouse clicks, searching for and calling click handler functions on GraphObjects or on Diagram, and raising the corresponding DiagramEvent.
A click on a GraphObject of the diagram will raise one of the following DiagramEvents: "ObjectSingleClicked", "ObjectDoubleClicked", or "ObjectContextClicked". This will also look at the corresponding click property: GraphObject.click, GraphObject.doubleClick, or GraphObject.contextClick. If the value is a function, this will call it, passing the current InputEvent and the GraphObject. If the value is null, it tries looking at the parent GraphObject.panel, and so on, walking up the visual tree until it finds the appropriate function to call. After calling the click function, if the value of InputEvent.handled is false, this method will continue walking up the visual tree looking for more click functions to call. Once it has looked at the top-level object (a Part) for a click function, this method stops.
A click in the background of the diagram will raise one of the following DiagramEvents: "BackgroundSingleClicked", "BackgroundDoubleClicked", or "BackgroundContextClicked". This will also look at the corresponding click property: Diagram.click, Diagram.doubleClick, or Diagram.contextClick. If the value is a function, this will call it, passing the current InputEvent.
This method is not responsible for selecting or deselecting any parts. Call standardMouseSelect for that functionality.
Note that this calls GraphObject.isEnabledObject on the target object; if it returns false, no click action will occur.
The ClickSelectingTool calls this method in its override of doMouseUp in order to raise "click" events. Note that by default GraphObjects in Layers that are Layer.isTemporary will not be "clicked". To change that behavior it is easiest to set GraphObject.isActionable to true on those objects for which you wish to handle "click" events. Then the ActionTool's doMouseUp override will raise the standard "click" events.
This method may be overridden, but you should consider calling this base method in order to get all of its functionality. Please read the Introduction page on Extensions for how to override methods and how to call this base method.
An optional custom navigation function to find target objects.
An optional custom predicate function to find target objects. No value means that only objects in layers holding permanent objects.
true if InputEvent.handled had been set to true on the Diagram.lastInput.
Implement the standard behavior for mouse enter, over, and leave events, where the mouse is moving but no button is pressed. This should be called by mouse move event handlers when wanting to detect and invoke mouse enter/over/leave event handlers.
The GraphObject.mouseEnter property provides a function to call when the mouse first enters an object or any of its contained objects (if the object is actually a Panel).
The GraphObject.mouseLeave property provides a function to call when the mouse leaves an object and all of its contained objects (if the object is actually a Panel).
The GraphObject.mouseOver property and Diagram.mouseOver properties provide functions to call when the mouse moves but stays within the same GraphObject or when the mouse moves in the background of the Diagram.
This method is also responsible for updating the Diagram.currentCursor according to the value of GraphObject.cursor and Diagram.defaultCursor.
This method may be overridden, but you should consider calling this base method in order to get all of its functionality. Please read the Introduction page on Extensions for how to override methods and how to call this base method.
Implement the standard behavior for selecting parts with the mouse, depending on the control and shift modifier keys.
Control-clicking on a part will select it if it wasn't already, and will deselect if it had been selected. Shift-clicking on a part will add it to the selection (if it wasn't already). Otherwise, clicking on a part will select it (if it wasn't already).
Note that there are restrictions on selection. For example, a part cannot be selected in this manner if Part.selectable is false, or if Diagram.maxSelectionCount would be exceeded.
A left click in the background of the diagram with no modifier keys clears the selection.
This method does not implement any click event behavior -- that is implemented by standardMouseClick.
The ClickSelectingTool calls this method in its override of doMouseUp in order to change the selection.
This method may be overridden, but you should consider calling this base method in order to get all of its functionality. Please read the Introduction page on Extensions for how to override methods and how to call this base method.
Implement the standard behavior for mouse wheel events. ToolManager.doMouseWheel calls this method.
Turning the mouse wheel if Diagram.allowVerticalScroll is true causes the diagram to scroll up or down. If InputEvent.shift and Diagram.allowHorizontalScroll are true, the diagram scrolls left or right.
If InputEvent.control and Diagram.allowZoom are true, turning the mouse wheel changes the diagram's scale, zooming in or out while trying to keep the point in the model at the same point as the mouse.
The value of ToolManager.mouseWheelBehavior affects what operations might occur upon mouse wheel events.
This method may be overridden, but you should consider calling this base method in order to get all of its functionality. Please read the Introduction page on Extensions for how to override methods and how to call this base method.
Continues pinch-zooming (started by standardPinchZoomStart on multi-touch devices.
This is called by ToolManager.doMouseMove if the Diagram.lastInput has InputEvent.isMultiTouch set to true and canStartMultiTouch returns true. By default this calls doCancel in order to cancel the regular tool behavior caused by the multitouch events. This then calculates the appropriate zoom level and calls CommandHandler.canResetZoom to decide whether to call CommandHandler.resetZoom to actually set Diagram.scale. This method may be overridden. Please read the Introduction page on Extensions for how to override methods and how to call this base method.
Initiates pinch-zooming on multi-touch devices.
This is called by ToolManager.doMouseDown if the Diagram.lastInput has InputEvent.isMultiTouch set to true and canStartMultiTouch returns true. This method may be overridden. Please read the Introduction page on Extensions for how to override methods and how to call this base method.
This is called to start a new timer to call doWaitAfter after a given delay. It first cancels any previously running "WaitAfter" timer, by calling cancelWaitAfter.
This is normally used to implement mouse hover and mouse hold events. If the mouse has moved, it must not have moved beyond the distance as determined by Tool.isBeyondDragSize for it be considered "stationary". So the regular ToolManager.doMouseMove implementation only calls this method when the mouse has moved beyond the drag size.
This method is rarely overridden. Please read the Introduction page on Extensions for how to override methods and how to call this base method.
The delay, in milliseconds.
An optional event that caused this timer. Defaults to Diagram.lastInput. This gets passed on to doWaitAfter.
Call Diagram.startTransaction with the given transaction name. This always sets transactionResult to null.
This is normally called in an override of doActivate, if the tool modifies the model, along with a call to stopTransaction in an override of doDeactivate. Alternatively, you can surround a block of code that sets the transactionResult with calls to startTransaction and stopTransaction.
a string describing the transaction.
the value of the call to Diagram.startTransaction.
If the Diagram.currentTool is this tool, stop this tool and start the Diagram.defaultTool by making it be the new current tool. The implementation of various tool methods can call this method to stop the current tool. This will call doStop -- you should not call that method directly.
If you want to stop the current tool and have it restore the original state, call doCancel. Please read the Introduction page on Extensions for how to override methods and how to call this base method.
If transactionResult is null, call Diagram.rollbackTransaction, otherwise call Diagram.commitTransaction.
This is normally called in an override of doDeactivate,
if startTransaction was called in doActivate.
Alternatively, you can surround a block of code that sets the transactionResult
with calls to startTransaction and stopTransaction.
This method may be overridden. Please read the Introduction page on Extensions for how to override methods and how to call this base method.
the result of the call to rollback or commit the transaction.
The diagram asks each tool to update any adornments the tool might use for a given part. If the tool uses its own tool handles, this should display them or hide them as appropriate. Typically this should only show them if the part is selected.
By default this method does nothing. This method may be overridden. Please read the Introduction page on Extensions for how to override methods and how to call this base method.
Tools handle mouse, keyboard, and touch events. The currently running tool, Diagram.currentTool, receives all input events from the Diagram via canonicalized InputEvents.
For more discussion, see Introduction to Tools. See samples that make use of tools in the samples index.
Most tools are "mode-less" tools that are managed by the ToolManager, which chooses the current tool based on the kind and position of the mouse event and the parts in the diagram. The ToolManager has properties holding instances of most of the pre-defined Tool classes. These classes include:
The ToolManager chooses a tool to run as the diagram's current tool by finding in its lists of tools the first tool whose canStart method returns true. The ToolManager then sets Diagram.currentTool to be that tool.
A tool is in the "running" state when it is the value of Diagram.currentTool. The Diagram.currentTool property setter will call doStop on the old tool and then call doStart on the new tool.
A tool can then go into the "active" state once it decides it can actually do something. This happens with a call to doActivate, normally called by the ToolManager. Later it is deactivated (doDeactivate) and then stopped. isActive should be true when the tool is "active". Often tools should ignore certain common events, such as calls to doMouseMove, unless the tool isActive.
You can prevent a "mode-less" tool (i.e. one managed by the ToolManager) from being started by the ToolManager by setting isEnabled to false.
You can also go into a particular "mode" by setting Diagram.currentTool explicitly, thereby circumventing the normal operation of the ToolManager. This ignores the isEnabled property and does not call the canStart predicate. The behavior will depend on the tool -- not all of the predefined tools support operating as a "modal" tool.
Tools cannot be shared amongst multiple Diagrams.
If you define a Tool subclass, you may override any of the methods whose names start with "do" and any other methods that are documented to be overridable, such as canStart. However you must seriously consider calling the base method in order to gets its default behavior. There may be situations where not calling the base method may cause subtle bugs. But that depends on the method and the tool. Please read the Introduction page on Extensions for how to override methods and how to call the base method.