Your Privacy Matters: We use our own and third-party cookies to improve your experience on our website. By continuing to use the website we understand that you accept their use. Cookie Policy
40
Forcing label edit to stay in Edit Mode breaks Editor behaviour
posted

Hello,

I am having a problem with editing nodes in a tree. The tree is set to standard, so BeginEdit() gives me the option to edit it. Now after the edit but before leaving Edit Mode I want to check if I can insert this into the database (value of the Text property on a node is part of the Primary key in the db)

Now I found the following http://news.infragistics.com/forums/p/3234/41606.aspx#41606

But the fix supplied gives an odd behaviour in my project. The event BeforeExitEditMode fires and if it passes my test case everything is OK. But if it fails while using the enter/return key and I consequently set e.Cancel = true;  the EditorWithText will break as in:

1) The editing field keeps active ( seems good! But!)

2) enter and escape or any other kind of 'leaving the node/textarea' no longer works or does not facilitate the expected behaviour. With expected behaviour I mean that it would fire BeforeExitEditMode again. But it won't, it will ignore all of that (except backspace and typing when it has the focus) If I select a different node, use the enter/return key or escape it will do absolutely nothing. The editing field will stay active and I can not seem to get rid of it.

 

this.ultraTree1.Override.Editor = new EditorWithText();
this.ultraTree1.EditorResolved.BeforeExitEditMode += new BeforeExitEditModeEventHandler(EditorResolved_BeforeExitEditMode);

private void EditorResolved_BeforeExitEditMode(object sender, BeforeExitEditModeEventArgs e) {

EmbeddableEditorBase editor = sender as EmbeddableEditorBase;

if ( editor != null )
    {
        try {

commitToDB(editor.CurrentEditText);

   } catch (Exception exc) {

e.Cancel = true; //when this happens my node editing breaks down.

   }

}

}

 

 

  • 69832
    Suggested Answer
    Offline posted

    I looked into this and the behavior does seem incorrect in that the node seems to think it got out of edit mode, like it doesn't know that the editor's BeforeExitEditMode event was canceled. You might want to report this.

    The ValidateLabelEdit event, however, handles this correctly. In the post you referenced, one of the requirements seemed to be that they wanted to get a notification even when the node's text hadn't changed; if this is not a concern for you, you should use ValidateLabelEdit instead.