When deleting an item in TreeListBox, the focus will be released to the top layer

Hello,

The TreeListBox control will try to select an ancestor item if the current selected item is removed.  However in this case you turned off IsRootItemVisible.  If the root item was visible, deleting one of the child nodes would move selection up to the root item and focus would remain within the control, on that parent item's TreeListBoxItem.

Without the root item visible, the code as you have it will effectively remove the selected item's TreeListBoxItem, which is currently focused.  When a focused WPF control is removed from the visual tree in general, WPF moves focus to the Window.  I think that's what's going on here.

A better way to do things is to update your view model to two-way bind to the TreeListBox.SelectedItem and make an appropriate SelectedItem change to an item not being removed, prior to removing an item.

If you do that, and also change your "x" Button to be Focusable="False", it will keep focus within the control as long as you have selected another remaining item.  The Focusable="False" is needed since the Button might be moving focus elsewhere after click.

Now the problem that remains is when there are no other remaining items to select, such as when you are removing the last item.  We will update our logic for the next build to focus the TreeListBox control itself when no selection remains after an item is removed.  That will handle this last case, and also if you didn't update the SelectedItem as suggested above.

Thanks for your reply.

Bidirectional binding of "SelectedItem" and then letting ViewModel notify TreeListBox to perform Focus behavior may be a relatively simple solution at present.

But it sounds like you need to solve the situation where IsRootItemVisible=false, otherwise the control will not allow users to produce a "product-level" project, because the premise is that we need to ensure that 80% of the code complies with the "data-driven" specification. It is not appropriate for us users to solve the "UIElement.Focus" problem, which will lead to an increase in development costs.

In addition, can you recommend a solution for custom control inheritance? I hope to reduce the difficulty of our development and maintenance.

Thanks again.

Hello,

We agree and I apologize if it wasn't described properly, but the last paragraph in our previous reply mentions that the update made should also handle if you don't change SelectedItem before deleting an item.  We still do recommend changing the SelectedItem to something appropriate in general though, but it won't be required to keep focus in the control after the update.

Regarding the custom control inheritance question, can you describe in more detail what you mean there and what specific challenges you are facing?  Thanks!

What I mean is that we use this control very frequently. From our perspective, the SelectedItem property does not undertake any business. If we prioritize solving the problem with this idea, the code will become more and more bloated and difficult to maintain.

Moreover, if this problem is solved after updating the Actipro package, the above code is not what we need, which is not what we want.

But we keep this suggestion because it is the simplest and most effective way to ensure the "data-driven specification" at present, but it will also face the dilemma of "deleting the last item" as you said.

So I put forward another idea: Can we solve this problem by customizing the control to inherit TreeListBox? Maybe I can set "this.Focus" after TreeListBox.SelectedItemChanged, but I don't know if this will bring more problems.

In this regard, do Actipro developers have any other better suggestions?

Hi David,

The simplest thing might be if you write our support address and mention this thread, we can send you a preview build that has our code update in it.  Then you can test with that and avoid having to do any additional work related to this issue.

OK, we will contact you via company email, maybe in a week. Thank you for your work.