diff --git a/api/index.html b/api/index.html index 2d9606ab0..b0c5279d3 100644 --- a/api/index.html +++ b/api/index.html @@ -24,7 +24,7 @@
  • API
  • Register
  • Download
    • -
  • Forum
    • +
  • Forum
  • Contact
  • Buy
  • Activate
    • @@ -970,7 +970,7 @@

    Collection Classes

    GoJS Class Index

    @@ -991,11 +991,11 @@

    GoJS Class Index

    ChangedEvent

    A ChangedEvent represents a change to an object, typically a GraphObject, but also for model data, a Model, or a Diagram. More... The most common case is for remembering the name of a property and the before-and-after values for that property.

    You can listen for changed events on the model using Model.addChangedListener and on the Diagram using Diagram.addChangedListener.

    There are four kinds of changes, represented by enumerated values: ChangedEvent.Property (the most common), ChangedEvent.Insert and ChangedEvent.Remove (to represent inserting or removing objects from collections), and ChangedEvent.Transaction (to notify about beginning or ending transactions or undo or redo).

    The most common kind of ChangedEvent is a Property change. The name of the property is given by #propertyName. The modified object is given by #object. Use the #oldValue and #newValue properties for the before and after property values.

    For an Insert ChangedEvent, the modified collection (often an Array) is a property value on the #object. The #propertyName helps distinguish between different collections on the object. Use the #newValue property to indicate the value that was inserted. Use the #newParam property to indicate where or how, such as an array index or dictionary key.

    For a Remove ChangedEvent, the modified collection is a property value on the #object. The #propertyName helps distinguish between different collections on the object. Use the #oldValue property to indicate the value that was removed. Use the #oldParam property to indicate where or how, such as an array index or dictionary key.

    Transaction ChangedEvents are generated by the UndoManager. The #propertyName names the nature of the ChangedEvent. For the very first transaction, the property name is "StartingFirstTransaction". This ChangedEvent precedes a ChangedEvent whose property name is "StartedTransaction", which occurs for every top-level transaction.

    When ending a transaction, there is first a ChangedEvent whose name is "ComittingTransaction". This is followed by one with either "CommittedTransaction" or "RolledBackTransaction", depending on how the transaction is ending. The #oldValue provides the transaction name and the #object is the Transaction being finished. (Note that the Transaction value may be null if no Transaction is available at that time, perhaps because there were no changes made during the transaction.) That Transaction can be scanned to look for ChangedEvents that you may wish to record in a database, all within a single database transaction.

    There are also Transaction ChangedEvents corresponding to "StartingUndo", "FinishedUndo", "StartingRedo", and "FinishedRedo". The #object property provides the Transaction that is about-to-be or just-was undone or redone.

    Non-Transaction ChangedEvents are remembered by the UndoManager, if UndoManager.isEnabled, and held in the UndoManager.history as Transactions which hold lists of ChangedEvents. That is why ChangedEvent implements undo and redo of the change that it remembers.

    When the ChangedEvent represents a change to a Model, the value of #model is non-null and the value of #diagram is meaningless. If the change is a structural change to the model, the value of #modelChange indicates the kind of change. Currently defined model changed event names include:

    The value of ChangedEvent.propertyName indicates the actual name of the property that was modified. ChangedEvent.modelChange is a non-empty string only when there is a known structural change to the model, not just the setting of some property on some object.

    When the ChangedEvent represents a change to a Diagram or a GraphObject within a diagram, the value of #diagram is non-null and the values of #model and #modelChange are meaningless.

    -

    CircularEdge

    This holds CircularLayout-specific information about Links.
    +

    CircularEdge

    This holds CircularLayout-specific information about Links. More...

    This class inherits from LayoutEdge.

    CircularLayout

    This layout positions nodes in a circular arrangement. More... There are several samples that use CircularLayout.

    If you want to experiment interactively with most of the properties, try the Circular Layout sample.

    This layout makes use of a LayoutNetwork of CircularVertexes and CircularEdges that normally correspond to the Nodes and Links of the Diagram.

    -

    CircularVertex

    This holds CircularLayout-specific information about Nodes.
    +

    CircularVertex

    This holds CircularLayout-specific information about Nodes. More...

    This class inherits from LayoutVertex.

    ClickCreatingTool

    The ClickCreatingTool lets the user create a node by clicking where they want the new node to be. More... By default a double-click is required to start this tool; set #isDoubleClick to false if you want a single-click to create a node.

    This tool is a standard mouse-up tool, the ToolManager.clickCreatingTool. However, it will not be able to start running unless you have set the #archetypeNodeData property to an object that can be copied and added to the diagram's model.

    This tool does not utilize any Adornments or tool handles. This tool does conduct a transaction when inserting the new node.

    @@ -1013,11 +1013,11 @@

    GoJS Class Index

    DragSelectingTool

    The DragSelectingTool lets the user select multiple parts within a rectangular area drawn by the user. More... There is a temporary part, the #box, that shows the current area encompassed between the mouse-down point and the current mouse point. The default drag selection box is a magenta rectangle. You can change the #box to customize its appearance -- see its documentation for an example.

    This tool is a standard mouse-move tool, the ToolManager.dragSelectingTool. However this cannot start running unless there has been a motionless delay after the mouse-down event of at least #delay milliseconds.

    This tool does not utilize any Adornments or tool handles, but it does temporarily add the #box part to the diagram. This tool does not modify the model or conduct any transaction.

    Selection occurs on a mouse-up when it calls #selectInRect with the value of #computeBoxBounds. Selectable parts are selected when their bounds fall entirely within the rectangle, unless #isPartialInclusion is set to true.

    If you implement your own drag-in-the-background-to-do-something tool, you may need to disable this tool or insert your new tool in the ToolManager.mouseMoveTools list before this tool, in order for your tool to run. There are two examples of such tools defined in the extensions directory: Drag Creating Tool and Drag Zooming Tool.

    -

    ForceDirectedEdge

    This holds ForceDirectedLayout-specific information about Links.
    +

    ForceDirectedEdge

    This holds ForceDirectedLayout-specific information about Links. More...

    This class inherits from LayoutEdge.

    ForceDirectedLayout

    Force-directed layout treats the graph as if it were a system of physical bodies with forces acting on them and between them. More... The algorithm seeks a configuration of the bodies with locally minimal energy, i.e. vertex positions such that the sum of the forces on each vertex is zero. There are many samples that use ForceDirectedLayout.

    If you want to experiment interactively with most of the properties, try the Force Directed Layout sample.

    This layout makes use of a LayoutNetwork of ForceDirectedVertexes and ForceDirectedEdges that normally correspond to the Nodes and Links of the Diagram.

    -

    ForceDirectedVertex

    This holds ForceDirectedLayout-specific information about Nodes.
    +

    ForceDirectedVertex

    This holds ForceDirectedLayout-specific information about Nodes. More...

    This class inherits from LayoutVertex.

    Geometry

    The Geometry class is used to define the "shape" of a Shape. More... A Geometry can be simple straight lines, rectangles, or ellipses. A Geometry can also be an arbitrarily complex path, consisting of a list of PathFigures.

    A Geometry must not be modified once it has been used by a Shape. However, a Geometry may be shared by multiple Shapes.

    @@ -1037,11 +1037,11 @@

    GoJS Class Index

    Layer

    Layers are how named collections of Parts are drawn in front or behind other collections of Parts in a Diagram. More... Layers can only contain Parts, such as Nodes and Links. They cannot hold GraphObjects directly.

    You put a Part into a Layer by assigning Part.layerName with the name of the Layer. You can use data binding to initialize and remember a Part's layer's name. You can change a Part's layer by modifying its Part.layerName, which changes its Part.layer.

    Each Diagram starts off with the following list of Layers: "Grid", "Background", "" (the default layer), "Foreground", "Adornment", "Tool". Parts are normally put in the default layer. The "Grid", "Adornment", and "Tool" layers are considered #isTemporary. Changes to objects in temporary layers are not recorded by the UndoManager. Parts in temporary layers are not selected and are not considered to be part of the document. The "Grid" layer is the furthest back; it also contains "temporary" parts that cannot be selected. Furthermore the "Grid" layer has #pickable set to false so that mouse or touch events and calls to the "find..." methods do not even consider any parts in that layer.

    Use Diagram.findLayer to get the Layer with a particular name. You can add your own layers by calling Diagram.addLayerBefore or Diagram.addLayerAfter to insert a new layer at a particular place in the Z-order, or to re-order existing layers.

    Layers have many properties that control what actions users are permitted to perform involving the parts in the layer. These properties are very much like the similarly named properties on Diagram.

    -

    LayeredDigraphEdge

    This holds LayeredDigraphLayout-specific information about Links.
    +

    LayeredDigraphEdge

    This holds LayeredDigraphLayout-specific information about Links. More...

    This class inherits from LayoutEdge.

    LayeredDigraphLayout

    This arranges nodes of directed graphs into layers (rows or columns). More... There are many samples that use LayeredDigraphLayout. If you want to experiment interactively with most of the properties, try the Layered Digraph Layout sample.

    If the diagram is structured in a tree-like fashion, it may be better to use TreeLayout, which has more options specific to trees. TreeLayout is much faster than LayeredDigraphLayout, and can handle a limited number of links that would prevent the graph structure from being a true tree (i.e. some nodes having multiple parents).

    This layout makes use of a LayoutNetwork of LayeredDigraphVertexes and LayeredDigraphEdges that normally correspond to the Nodes and Links of the Diagram.

    The layout algorithm consists of four-major steps: Cycle Removal, Layer Assignment, Crossing Reduction, and Straightening and Packing.

    -

    LayeredDigraphVertex

    This holds LayeredDigraphLayout-specific information about Nodes.
    +

    LayeredDigraphVertex

    This holds LayeredDigraphLayout-specific information about Nodes. More...

    This class inherits from LayoutVertex.

    Layout

    This is the base class for all of the predefined diagram layout implementations. More... They only arrange Parts (primarily Nodes and Links) in a Diagram, not to GraphObjects in Panels (i.e. panel layout).

    The layout classes include TreeLayout, ForceDirectedLayout, LayeredDigraphLayout, CircularLayout, and GridLayout. This base class is not abstract -- in fact an instance of this base class is the default value for Diagram.layout and for Group.layout.

    An instance of a Layout class will be the value of Diagram.layout. That layout positions the graph of top-level nodes and links. Nodes and links that belong to a Group are laid out by that group's Group.layout. The Diagram will automatically perform all nested group layouts before laying out the whole diagram.

    If you have position information for all of the nodes when you load a model, you will typically have data bound the Part.location to some property on your node data. In order to avoid an initial layout causing those saved node positions to be discarded, you can either not set the Diagram.layout to a predefined layout or you can set #isInitial to false.

    Because performing layouts can be expensive in space and time, automatic layouts are performed only on "invalid" layouts, and only well after a layout has been invalidated. This state is held by the #isValidLayout property. Many standard operations, such as adding or removing nodes or links, will cause the layout that is responsible for positioning those nodes or routing those links to be invalidated. Such invalidation is performed by calling #invalidateLayout, which not only clears the #isValidLayout state but also requests that the diagram do an automatic layout soon. You can avoid such invalidations by setting #isOngoing to false.

    Layouts will ignore parts that have Part.isLayoutPositioned set to false or parts that are not GraphObject.visible. Layouts will also ignore parts that are in layers that are Layer.isTemporary.

    Various operations on Parts will cause the responsible Layout to be invalidated. This includes adding or removing parts, changing their visibility, and changing their size. You can disable such automatic layout invalidations by setting Part.layoutConditions to the combination of Part flags named "Layout..." that you want.

    But operations on parts are not the only way in which layouts become invalidated. Setting most properties on the layouts, thereby changing their behavior, will invalidate that layout. Replacing the Diagram.layout or Group.layout will automatically invalidate the new layout. If #isViewportSized is true, when a diagram's Diagram.viewportBounds changes size, the Diagram.layout is invalidated. (This is normally only true for GridLayouts when its GridLayout.wrappingWidth is NaN. Most layouts do not care about the size of the viewport.)

    You can also explicitly call Diagram.layoutDiagram, which can invalidate all layouts and then perform them all. But we recommend that you avoid doing so, to allow the normal updating process perform layouts as needed.

    If an automatic layout is the first time that a layout has been performed for the model, the diagram first raises the DiagramEvent named "InitialLayoutCompleted". Whenever a Diagram finishes an automatic layout, it raises the DiagramEvent named "LayoutCompleted".

    It is also possible to call #doLayout explicitly, but this is uncommon and only used with instances of Layout that are not the Diagram.layout or Group.layout. It should only be needed when you want to layout a collection of nodes and links that is not the normal graph of top-level parts of a Diagram or a subgraph of a Group.

    More complicated layouts make use of a separate LayoutNetwork, consisting of LayoutVertexes and LayoutEdges, that normally holds a graph that is isomorphic to the graph consisting of Nodes and Links in the Diagram or Group. The implementation of #doLayout will call #makeNetwork and remember the result as the #network. #makeNetwork will call #createNetwork and initialize it by adding new instances of LayoutVertexes and LayoutEdges corresponding to the given collection of Nodes and Links.

    When #doLayout is finished with its work it will call #updateParts, which will call #commitLayout to set new node locations and route links. It then normally discards the #network.

    The LayoutVertex and LayoutEdge instances allow the layout to work with more information about each Node and Link without actually modifying those Nodes and Links until #commitLayout is called to actually set the Node locations and route the Links. The use of a LayoutNetwork also allows the Layout to work with a graph that is not isomorphic to the given collection of Nodes and Links. This is useful when needing to use dummy vertexes and/or edges to achieve certain layout behaviors, or when one wants to ignore certain vertexes or edges, without actually modifying or adding or removing the diagram's nodes or links.

    An instance of this base class provides a rudimentary default layout that will position all of the parts that have no position (i.e. the Part.location is (NaN,NaN). Parts that already have a position are ignored. This primitive layout class does not make use of a LayoutNetwork because it ignores all links.

    To implement your own custom layouts, you can inherit from either this class or from one of the other predefined layout classes. If you inherit from this base class, you will want to override the #doLayout method. You can call the Part.move method to re-position a part, including whole groups. Please read the Introduction page on Extensions for how to override methods and how to call a base method.

    @@ -1117,13 +1117,13 @@

    GoJS Class Index

    Transaction

    A Transaction holds a list of ChangedEvents collected during a transaction, as the value of the read-only #changes property. More...

    Start a transaction by calling UndoManager.startTransaction (or Model.startTransaction or Diagram.startTransaction, which call that method). Be sure to finish a transaction with a matching call to UndoManager.commitTransaction (or Model.commitTransaction or Diagram.commitTransaction), or a call to UndoManager.rollbackTransaction (or the same named methods on Model or Diagram).

    If you are performing multiple or repeated changes to a model or diagram, surround all of the code with calls to start and commit the transaction -- do not perform repeated calls to start-commit-start-commit. Typically each change caused by the user, such as a button click or a change of focus or a mouse drag, should perform one transaction in which all changes are made. All of the predefined commands and tools perform transactions.

    Undoing or redoing a transaction is done by calling UndoManager.undo or UndoManager.redo. Those methods call the undo or redo methods here.

    The UndoManager holds a list of Transactions in its UndoManager.history.

    -

    TreeEdge

    This holds TreeLayout-specific information about Links.
    +

    TreeEdge

    This holds TreeLayout-specific information about Links. More...

    This class inherits from LayoutEdge.

    TreeLayout

    This layout positions nodes of a tree-structured graph in layers (rows or columns). More... For a discussion and examples of the most commonly used properties, see Trees page in the Introduction. There are many samples that use TreeLayout. If you want to experiment interactively with most of the properties, try the Tree Layout sample.

    This layout makes use of a LayoutNetwork of TreeVertexes and TreeEdges that normally correspond to the Nodes and Links of the Diagram.

    The most commonly set properties for controlling the results of a TreeLayout are:

    • #angle: the direction in which the tree grows, from parent to child; the default value of zero means that the tree grows towards the right, with the children of a node arranged in a layer that is a column. An angle of 0 or 180 means that children form vertical layers -- breadth is height and depth is width; an angle of 90 or 270 means that children form horizontal layers -- breadth is width and depth is height.
    • #layerSpacing: the distance between layers -- between a parent node and its child nodes.
    • #nodeSpacing: the distance between nodes within a layer -- between siblings.
    • #alignment: the relative position of a parent node with its children.
    • #sorting and #comparer: specify the order of the immediate children of a parent node.
    • #compaction: whether subtrees should be packed closer together if there is room.
    • #layerStyle: whether the children of one node are aligned with the children of a sibling node.
    • #setsPortSpot, #portSpot, #setsChildPortSpot, and #childPortSpot: this controls whether to set the Link.fromSpot and Link.toSpot to be sensible for the #angle.
    • #nodeIndent and #nodeIndentPastParent: if the #alignment is TreeLayout.AlignmentStart or TreeLayout.AlignmentEnd, control how much extra space the first child is given when positioned.
    • #breadthLimit, #rowSpacing: try to limit the total breadth of a subtree to a certain distance; when there are too many children or when they are too broad, this puts children into additional rows (or columns, depending on the angle) thereby limiting the breadth while increasing the depth of the tree.

    When you set one of the TreeLayout properties listed above, that property normally applies to all of the nodes in the tree. What if you want #alignment to be TreeLayout.AlignmentCenterChildren for the root node but TreeLayout.AlignmentBus for the other nodes in the tree? Or what if you want want #layerSpacing to be 50 for all layers except for the layer separating "leaf" nodes from their parent?

    One common solution is to set #treeStyle. For the former scenario, you could set #treeStyle to TreeLayout.StyleRootOnly; the value of #alignment would only apply to the root node. For the latter scenario, you could set it to TreeLayout.StyleLastParents; the value of #layerSpacing would apply to all nodes except those that have children but that do not have grandchildren. How do you then set the alignment or layerSpacing for the other nodes? By setting the TreeLayout properties whose names start with "alternate...". In these cases that would mean setting #alternateAlignment or #alternateLayerSpacing.

    These TreeLayout properties actually apply to the TreeVertex that the TreeLayout uses to represent a Node within the TreeNetwork. All of those TreeLayout properties are actually stored in #rootDefaults; all of the "alternate..." properties are stored in #alternateDefaults. Depending on the value of #treeStyle, the actual TreeVertex properties for each Node are copied appropriately from either rootDefaults or alternateDefaults. In the default case where treeStyle is TreeLayout.StyleLayered, the alternateDefaults are ignored. (Note that treeStyle, and a few other properties such as #path and #arrangement, apply to the whole layout, not to an individual node/vertex.)

    The use of #treeStyle and "alternate..." TreeLayout properties will cover a lot of common needs for tree layout customization. However, there may be times when that is not enough. Imagine a situation where you want a special TreeVertex property value for a particular Node. The solution is to override #assignTreeVertexValues, where you can examine the given TreeVertex, including its corresponding LayoutVertex.node, to decide what TreeVertex property values should apply.

    TreeModel

    TreeModels support tree-structured graphs of nodes and links. More... Each node can have at most one "tree parent"; cycles are not permitted. The reference to the parent node's key is a property of the child node data.

    TreeModels, unlike GraphLinksModels, do not support arbitrary link relationships between nodes, nor is there a separate link data object for each parent-child relationship. Furthermore there is no support for grouping or label nodes.

    The #nodeParentKeyProperty property names the property on the node data whose value is the key of the "tree parent" node. The default value for this property is "parent".

    For example, one can define a graph consisting of one parent node with two child nodes: 

     model.nodeDataArray = [
   { key: "Alpha" },
   { key: "Beta", parent: "Alpha" },
   { key: "Gamma", parent: "Alpha" }
 ];

    If you need to show a more complicated graph structure than a tree, use a GraphLinksModel. If you want to have multiple links between the same pair of nodes, or if you want to associate more information with each link and cannot put the information on the child node, you will need to have a separate link data object for each link, and that would require the use of GraphLinksModel.

    -

    TreeVertex

    This holds TreeLayout-specific information about Nodes.
    +

    TreeVertex

    This holds TreeLayout-specific information about Nodes. More...

    This class inherits from LayoutVertex.

    UndoManager

    UndoManager observes and records model and diagram changes in transactions and supports undo/redo operations. More... You will need to set the isEnabled property to true in order for users to perform an undo or a redo.

    Typically an operation will call startTransaction, make some changes to the Model or Diagram, and then call commitTransaction. Any ChangedEvents that occur will be recorded in a Transaction object. If for some reason you do not wish to complete the transaction successfully, you can call rollbackTransaction instead of commitTransaction.

    The history property is a list of Transactions. commitTransaction will add the currentTransaction to the history list. rollbackTransaction will undo the changes remembered in the currentTransaction and then discard it, without changing the history. You can limit how many transactions are remembered in the history by setting maxHistoryLength.

    Transactions may be nested. Be sure to call either commitTransaction or rollbackTransaction for each call to startTransaction. Avoid repeated start-commit-start-commit calls as a result of a user's actions. Instead, start, make all changes, and then commit.

    If you want to restore the diagram to the state before the latest complete transaction, call undo. Call redo to change the diagram to a later state. If after some number of undo's you start a transaction, all of the history after the current state is discarded, and a new transaction may be recorded. You cannot undo or redo during a transaction.

    Initially each Model has its own UndoManager. UndoManagers may be shared by multiple Models by replacing the standard Model.undoManager created by the model constructor.

    There are several informational properties:

    diff --git a/api/symbols/ActionTool.html b/api/symbols/ActionTool.html index 960bb3154..782e59193 100644 --- a/api/symbols/ActionTool.html +++ b/api/symbols/ActionTool.html @@ -25,7 +25,7 @@
  • API
  • Register
  • Download
    • -
  • Forum
    • +
  • Forum
  • Contact
  • Buy
  • Activate
    • @@ -974,7 +974,7 @@

    Collection Classes

    diff --git a/api/symbols/Adornment.html b/api/symbols/Adornment.html index d05c5495a..35a542ce2 100644 --- a/api/symbols/Adornment.html +++ b/api/symbols/Adornment.html @@ -25,7 +25,7 @@
  • API
  • Register
  • Download
    • -
  • Forum
    • +
  • Forum
  • Contact
  • Buy
  • Activate
    • @@ -974,7 +974,7 @@

    Collection Classes

    diff --git a/api/symbols/AnimationManager.html b/api/symbols/AnimationManager.html index dc9ee0d41..5704123ea 100644 --- a/api/symbols/AnimationManager.html +++ b/api/symbols/AnimationManager.html @@ -25,7 +25,7 @@
  • API
  • Register
  • Download
    • -
  • Forum
    • +
  • Forum
  • Contact
  • Buy
  • Activate
    • @@ -974,7 +974,7 @@

    Collection Classes

    diff --git a/api/symbols/Binding.html b/api/symbols/Binding.html index 4f4a629d1..599668677 100644 --- a/api/symbols/Binding.html +++ b/api/symbols/Binding.html @@ -25,7 +25,7 @@
  • API
  • Register
  • Download
    • -
  • Forum
    • +
  • Forum
  • Contact
  • Buy
  • Activate
    • @@ -974,7 +974,7 @@

    Collection Classes

    diff --git a/api/symbols/Brush.html b/api/symbols/Brush.html index 733017760..4930ed7a6 100644 --- a/api/symbols/Brush.html +++ b/api/symbols/Brush.html @@ -25,7 +25,7 @@
  • API
  • Register
  • Download
    • -
  • Forum
    • +
  • Forum
  • Contact
  • Buy
  • Activate
    • @@ -974,7 +974,7 @@

    Collection Classes

    diff --git a/api/symbols/ChangedEvent.html b/api/symbols/ChangedEvent.html index 170af82df..c0d54c5a2 100644 --- a/api/symbols/ChangedEvent.html +++ b/api/symbols/ChangedEvent.html @@ -25,7 +25,7 @@
  • API
  • Register
  • Download
    • -
  • Forum
    • +
  • Forum
  • Contact
  • Buy
  • Activate
    • @@ -974,7 +974,7 @@

    Collection Classes

    diff --git a/api/symbols/CircularEdge.html b/api/symbols/CircularEdge.html index 3130b4430..488b3dcc0 100644 --- a/api/symbols/CircularEdge.html +++ b/api/symbols/CircularEdge.html @@ -5,34 +5,34 @@ GoJS® CircularEdge Class - - - - - - + + + + + + -
    - -
    - +
    + +
    +