In my last post I described how to extend the default label
edit functionality of a
TreeView control to be somewhat more
flexible, by allowing you to specify custom text other than
blindly using the text of the
TreeNode being edited.
This post will extend the original code to include custom validation. For example, you may wish to restrict the available characters, or check to see if the value entered doesn't match an existing value.
The code in this article assumes you have a base class that includes the enhancements from the previous post, or you can download the complete example from the link at the end of the article.
Firstly we need to add a new event that will present the
proposed change and allow the implementer to validate it. As
this is event won't allow the label to be modified, we can use
NodeLabelEditEventArgs class rather than the
custom class we created in the previous post.
We also need a backing variable to store the current text string in the event of a validation error in order to correctly re-initialize the edit field.
In our extended
TreeView component, we had overridden
OnAfterLabelEdit in order to obtain the new display text after
a successful edit. We're going to modify this override slightly
in order to handle validation.
Here, we automatically cancel the default handling of the label edit, as regardless of whether validation passes or not, we'll be updating node text manually.
First we raise our
ValidateLabelEdit event, passing in the
TreeNode to be edited, and the proposed label text. If the
CancelEdit property of the passed
true, then validation has failed.
If validation does fail, we update the
we defined earlier with the current label text, then
automatically switch the control back into label editing mode.
There's just one thing left to change. As with
OnAfterLabelEdit, we had also overridden
OnBeforeLabelEdit in order to modify the text displayed in the edit field. We'll need to modify this to provide the current label value if a validation error occurs, otherwise the text will reset to whatever the original value was before editing started. Of course, in the event of a validation error you want he user to be able to retry with the modified value to allow correction of the error. To do this, we'll modify the block of code that obtained the text to display to use the new
_postEditText variable and to skip raising the
RequestEditText event if its set. We'll also reset the
null so that the next time an edit is started, it reverts to the original behaviour. Unless it's another validation error for the current edit operation of course!
And that is it. Extremely simple, but very useful if you need to validate this sort of input!
The sample project available with this article demonstrates validation, as shown in the following snippet.
As can be seen from the simple animation at the start of the article, the edit field is hidden and the original node text displayed, validation occurs, then editing restarts in the event of an error. This means, if you display a message box for example, the original tree state is displayed. It also means that the cursor and selection state of the edit field is lost. Ideally, it would be preferable to do validation without causing the edit field to vanish first, but that would require some more p-invoke, and probably isn't necessary for most cases - this method keeps the users entered text which is the important bit.
- 2013-10-28 - First published
- 2020-11-21 - Updated formatting, corrected misspellings
Like what you're reading? Perhaps you like to buy us a coffee?
- Extending the LabelEdit functionality of a TreeView to include validation
- Specifying custom text when using the LabelEdit functionality of a TreeView