Adding and Editing Labels
GraphEditorInputMode supports interactively adding and editing labels. The most prominent options to control label editing are presented in the Adding and Editing Labels section. You can further customize the process of adding or editing labels by overriding the shouldAddLabel and shouldEditLabel methods. For example, you could disallow adding or editing specific labels under certain circumstances. The following example shows how to ensure that label owners have no more than a single label by restricting adding labels appropriately:
Furthermore, you can use the following two events to achieve very similar results to overriding the above methods:
Event | Occurs when … |
---|---|
They allow you to change the label editing process completely by calling appropriate methods on their event argument. That argument, a LabelEditingEventArgs instance, offers various properties to customize editing labels. For example, to achieve the same result as the overloaded shouldAddLabel method above, you can also use the following event listener:
Apart from the cancel property you can also set a different style, label layout parameter, or even redirect the editing process to a completely different label.
GraphEditorInputMode offers a number of other events that allow you to react to certain stages in label editing:
Event | Occurs when … |
---|---|
true
to prevent setting an invalid label text. This results either in a new label
not being added, or an existing label not changing its text.
You can also change the text to a different value to implement validation that
does not reject new values, but rewrites them. |
The LabelAdding and LabelEditing events offer quick and easy customization for all items. To change behavior only for certain label owners or labels, you can also decorate the lookup with a custom implementation of IEditLabelHelper. This interface defines two callback methods that are functionally identical to the LabelAdding and LabelEditing events on GraphEditorInputMode.
While the overall process of adding and editing labels is handled by GraphEditorInputMode, the actual text editor is managed by TextEditorInputMode.
Most prominently, TextEditorInputMode displays
a div element containing a textarea
which you can obtain from its
editorContainer property and customize
as necessary. For example, you can implement custom validation code that rejects
typed characters during editing (as opposed to the
GraphEditorInputMode.ValidateLabelText event which can only reject a
label text after the user pressed Enter ↵)
by adding a suitable keypress
to the container:
TextEditorInputMode also provides a number of events to listen to:
Event | Occurs when … |
---|---|
The LabelEditingEventArgs used in GraphEditorInputMode’s LabelAdding and LabelEditing events as well as IEditLabelHelper’s methods provides the textEditorInputModeConfigurator property which you can use to configure the TextEditorInputMode for a given label.
CSS Transition or Animation for the Input Element
The text input element has different CSS classes during entering or leaving the DOM with which CSS transitions or animations can be defined.
The transition or animation can be disabled separately by not defining any of the related CSS classes which are explained in the following sections.
Enter Phase
The following CSS classes are present when the input element is added to the DOM:
yfiles-labeleditbox-container-entering
This CSS class is present during the entire enter phase and can be used to define CSS transition or animation functions. It is removed when the enter transition or animation ends.yfiles-labeleditbox-container-enter
Initializes the start state of the input element. The class is added before the element is inserted in the DOM and removed just after the element was added to the DOM.yfiles-labeleditbox-container-enter-to
Defines the end state of the input element. This class is added whenyfiles-labeleditbox-container-enter
is removed, i.e. just after the element entered the DOM, and it is removed when the CSS transition or animation ends.
By default, yFiles comes with a simple fade transition for the enter phase of the input element:
.yfiles-labeleditbox-container-enter {
opacity: 0;
}
.yfiles-labeleditbox-container-enter-to {
opacity: 1;
}
.yfiles-labeleditbox-container-entering {
transition: opacity 0.1s ease-in;
}
Alternatively, you could also define a CSS animation, e.g.
@keyframes fade {
from { opacity: 0 }
to { opacity: 1 }
}
.yfiles-labeleditbox-container-entering {
animation: fade 0.1s ease-in;
}
Leave Phase
The following CSS are present when the input element leaves the DOM:
yfiles-labeleditbox-container-leaving
This CSS class is present during the entire leave phase and can be used to define CSS transition or animation functions. It is removed when the enter transition or animation ends.yfiles-labeleditbox-container-leave
Initializes the beginning of the leave state of the input element. The class is added when the leave phase begins and is removed just a frame later, whenyfiles-labeleditbox-container-leave-to
is set.yfiles-labeleditbox-container-leave-to
Defines the end state of the input element before it is removed from the DOM eventually. This class is added whenyfiles-labeleditbox-container-leave
is removed and it is removed when the CSS transition or animation ends. Thetransitionend
oranimationend
event also defines when the element is removed from the DOM.
By default, yFiles comes with a simple fade transition for the leave phase of the input element:
.yfiles-labeleditbox-container-leave {
opacity: 1;
}
.yfiles-labeleditbox-container-leave-to {
opacity: 0;
}
.yfiles-labeleditbox-container-leaving {
transition: opacity 0.1s ease-out;
}
Alternatively, you could also define a CSS animation, e.g.
.yfiles-labeleditbox-container-leaving {
animation: fade reverse 0.1s ease-out;
}