Editing RadTreeViewItem - setting e.Handled = true pushes tree out of edit mode.

[Rob]

Hello Telerik,

I'm working with a RadTreeView and editing items.  I have noticed a behavior that I think is a little odd.

1. I have attached the following events to my RadTreeView: PreviewEditStarted, EditStarted, PreviewEdited, Edited, PreviewEditCancelled, EditCancellled.
2. In my handler for PreviewEdited, I test for a validation (pretend it's a simple sting length test for simplicity) and set "e.Handled = true" when the validation fails.  I expected that this would stop the chain of tree editing events and I would be left in edit mode for the user to fix their problems.
3. Now for the strange behavior....
   •  if I have the edit popup open, enter my text, and press <enter> it works as I expect.  The user gets the error and is left in edit mode to fix their mistake.
   • HOWEVER, if I have the edit popup open, enter my text and press <tab> instead, the validation fires, e.handled is set to true, but I also get the cancel events and the user is kicked out of edit mode...
   • A third option, if I have the edit popup open, enter VALID text and press <tab>, the item is edited correctly and the user is pushed out of edit mode.

So my question is, is this by design?  Or a bug as I see it...  My thoughts are that both the <tab> and <enter> key (and any other way to navigate out of the cell except for explicitly cancelling with <esc>) should fail and leave the user in edit mode...  This would make it similar to a program like excel, for example, try editing a cell and typing "==sum((" to see an error that keeps you in edit mode regardless of <enter> or <tab>)

[Hristo]

Hello,

When TreeViewItem loses the focus the edit is completed. Thus pressing tab, completes the edit and pushes you out of edit mode. When you have incorrect value in the edit and press tab the edit is canceled and you are pushed out of edit mode again, but this time there is no change to the value. This is by design and not a bug in the TreeView implementation.
You could handle the KeyDown event when Tab is pressed to forbid focus navigation out of the item when the edit input is invalid.

All the best,
Hristo
the Telerik team

[Rob]

Hi Hristo - It seems like the KeyDown event fires after the PreviewEdited event.  My validation occurs in "PreviewEdited", which changes "IsEditing" to false before KeyDown occurs so I'm unsure as to how I go about blocking the focus change with bad input...

[Hristo]

Hi Rob,

You are right about the event sequence. I'm sorry for misleading you.
I've investigated the code and found a way to implement your case. I'm attaching a sample project demonstrating the approach. I would recommend you to place several debug statements writing to the output window in order to understand event sequence.

I'll try to explain it in brief.
When tab is pressed, edit tries to complete (PreviewEdited event is fired). I'm performing a validation check for the new value. if the value is not valid I'm handling the event in order to forbid the edit to complete and raising a flag indicating wrong input on edit completion.
Then the TreeView tries to cancel the edit (PreviewEditCanceled event is fired). I'm handing this event in order to stay in edit mode (otherwise edit will be canceled and the node will return to normal non editing state).
Finally, key down event is fired. Because this event has been already handled (for escape and tab keys) I'm using AddHandler in order hear the handled events too. Statements in this handler are self explanatory: when invalid input is present and the tab is pressed, I'm handling the tab press key in order to interrupt the focus navigation;if escape key is pressed, I'm canceling the edit.

Hope this helps. Please let me know if you need more info or the approach does not work in your case.

Kind regards,
Hristo
the Telerik team

[Rob]

Thanks Hristo.  Looks like it works so far!

[Hristo]

Hi,

Glad to hear it. Don't hesitate to contact us if any issues appear.

All the best,
Hristo
the Telerik team

[bhargava]

Hi Hristo,
I have the same problem as rob.I have tired the solution you have provided.I have made change in PreviewEdited to show the exception using Alert() and it is opens alert() twice.

private void xTreeView_PreviewEdited(object sender, Telerik.Windows.Controls.RadTreeViewItemEditedEventArgs e)
            {
            var data = ((RadContextMenu.BusinessItem)(e.NewValue));

            if (data.Name.Equals("error"))
                {
                e.Handled = true;
                this.invalidInputCommitAttempt = true;
                RadWindow.Alert("Hello from alert");
                }
            else
                {
                this.invalidInputCommitAttempt = false;
                }
            }

Thanks,
Bhargav

[Martin Ivanov]

Hi Bhargav,

The alert is opened twice because the PreviewEdited event is fired twice. In general, the PreviewEdit is called in few cases - for example, when you hit  the Enter key or when the tree view item lost its focus.

In your scenario when you hit enter the PreviewEdited is fired and the RadWindow is opened. The window gets the focus and the PreviewEdited event is fired for second time.

To work this around you can use a boolean flag which will determine if the window should be opened.However, this won't prevent the lost of focus from the edit box. You can set back the focus on the edit box after your close the RadWindow in its Closed event. For your convenience I updated the Hristo's project to demonstrates this approach. Please give it a try and let me know if it works for you.

In addition, here is the modification in the project's implementation:

private bool isAlertOpen = false;
private RadTreeViewItem editedItem;
private void xTreeView_PreviewEdited(object sender, Telerik.Windows.Controls.RadTreeViewItemEditedEventArgs e)
{
    var data = ((SampleBinding_SL.BusinessItem)(e.NewValue));

    if (data.Name.Equals("error"))
    {
        e.Handled = true;
        if (!this.isAlertOpen)
        {
            RadWindow.Alert(new DialogParameters()
            {
                Content = "Error!",
                Closed = MainPage_Closed
            });

            this.isAlertOpen = true;
            this.editedItem = e.OriginalSource as RadTreeViewItem;
        }
        else
        {
            this.isAlertOpen = false;
        }

        this.invalidInputCommitAttempt = true;
    }
    else
    {
        this.invalidInputCommitAttempt = false;
    }
}

private void MainPage_Closed(object sender, WindowClosedEventArgs e)
{
    TextBox editBox = this.editedItem.FindChildByType<TextBox>();
    editBox.Focus();
    this.editedItem = null;
}

I hope this helps.

Regards,
Martin
Telerik

 

 

[bhargava]

Hi Martin,
Thanks for the solution.It has partially solved the issue.I am using a radwindow on which I display this alert().Now, alert() is being displayed on back of the window.
Please check the image.

[bhargava]

This was the image I was referring to.

Thanks,
Bhargav

[Martin Ivanov]

Hi Bhargav,

I am not sure that I completely understand your case. What do you mean by saying that you are using a RadWindow on which you display the alert? Can you please send me a runnable code that demonstrates this behavior so that I can investigate what is causing it?

Thank you for any help you can provide.

Regards,
Martin
Telerik

 

 

[bhargava]

Hi Martin,

I have solved the issue. This was my issue , I was trying to display a radwindow and which on error displays an alert message to user. The alert message box was appearing on back/behind of the radwindow. I changed the radwindow to  a view.  I couldnt solve the original issue.

[Martin Ivanov]

Hello Bhargav,

I am glad to hear that you solved the in your application. If you need any further assistance related to our components please do not hesitate to contact us again.

Regards,
Martin
Telerik