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

Grids for WPF Forum

Posted 2 months ago by david lin
Version: 24.1.4
Avatar

Hello, Actipro developers. I am using Actipro's WPF controls.

Now I found a behavior: when deleting an item in TreeListBox, WPF's focus will be released to the top layer. This will seriously affect the user experience of DocumentWindow.

I know that there will be some focus-acquiring behaviors when updating ItemsControl and ItemsSource, but I have never encountered the behavior of releasing focus.

If possible, please tell me a way to get the focus other than "UIElement.Focus" or any other method, because this is not a "best practice".

Attached is my simplest Demo.

Comments (6)

Answer - Posted 2 months ago by Actipro Software Support - Cleveland, OH, USA
Avatar

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.


Actipro Software Support

Posted 2 months ago by david lin
Avatar

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.

Posted 2 months ago by Actipro Software Support - Cleveland, OH, USA
Avatar

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!


Actipro Software Support

Posted 2 months ago by david lin
Avatar

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?

Posted 2 months ago by Actipro Software Support - Cleveland, OH, USA
Avatar

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.


Actipro Software Support

Posted 2 months ago by david lin
Avatar

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

The latest build of this product (v24.1.5) was released 4 days ago, which was after the last post in this thread.

Add Comment

Please log in to a validated account to post comments.