I’m making an application that has two areas: a table on the left side of application window. The table is simple, just data, row by row, and columns for some major characteristics of items in a row. And the second area is a panel on the right side of the window similar to the Properties panel in Visual Studio WPF designer. This panel displays some additional properties of selected item/row in the table. That simple)
So, when a user selects an item in the table, the underlying code finds the corresponding iew model for the additional properties of that item and binds this VM to the properties panel control. Those additional properties can be changed.
Unfortunately, the time needed to bind properties view-model is pretty long, and there is no way to decrease it. And the user gets annoyed very fast, because he needs to wait a short period of time to see the properties of selected item. Even more, often he selects an item by mistake and wants to switch to other one without delays. But because of the slow bindings he has to wait.
I thought that it was something wrong with my architecture design. But, surprisingly, I found almost the same behaviour in VS WPF designer. When you rapidly click controls on the window, the Properties panel needs some noticeable time to display the control properties. The only difference with my code is that in VS you can still click on widow element and they are not going frozen while their properties are loading in the Propertis panel. On the contrary, in my app the window freezes for a while, when I’m trying to select table rows rapidly.
So, the obvious solution is to somehow abort the ongoing binding procedure for the previously selected row and then run new binding procedure for the newly selected row. This should obviously include some async staff. But I do not have control over binding mechanics of XAML and WPF. So the question is how to implement such non-blocking behaviour in UI similar to VS WPF designer? I could not find something in Google(( Maybe it should be something with multiple UI threads, but I think it would be a very complex solution to have multiple UI threads on the same WPF window.
I would be very grateful for the solution and code example)