Tweets by @Actipro
Please take some time to learn more about us and our product offerings.
In the last blog post on our TreeListBox control development, we gave a list of features that have been implemented so far and showed a screenshot of sample usage with rendering customization. In today's post, we'll show some more usage scenarios, will request your immediate input for drag/drop, and will give an updated feature list.
First, what's new since the last post? We now have multiple options for governing if and when the determination of expander display is made for a node. This is handy when you want to do minimal data model access checking for children, or when you know for certain that a node never has child nodes.
We now support optional async loading features where you'll be able to utilize a new RingSpinner control (or any other busy indicator) to relay a loading state to the end user. Async loading means that potentially lengthy operations such as file or database access won't block the UI thread when expanding a node.
Here's an example of async loading, where a simulated random delay is invoked when expanding each file folder:
Notice how the UI remains fully responsive even while loading items.
Inline editing is fully supported when enabled. Press F2 or single click on a node's content to enter edit mode where a new text value can be entered. Pressing Enter or losing focus commits the value, while pressing Esc cancels the edit.
An event will fire when an item requests a context menu. Dynamically create the menu for that particular item (or the entire multi-item selection).
Drag and drop is one of the last features we want to get in place before an alpha test version is prepared of the control. This is a complex topic since it involves single/multi-selected items (that could be at various tree depths) being dragged and dropped at other depths, or even dragged externally. Likewise, external items could be dragged onto the control. We want to get your feedback now as we start on drag/drop features to ensure we meet all your needs!
Please either write our support address with your feedback or join our Slack discussion on the topic and chat right with us. The benefit of the chat option is that we are posting screenshots and asking for feature input right during development. It gives you an opportunity to give direct feedback and help guide features.
Thus far these features have been completed (New! marks new features since the last post):
The TreeListBox control continues to progress well and its feature set is coming right in line with the VS Solution Explorer's tree control's feature set. We look forward to discussing drag/drop feature requirements with you via our ticket system or in Slack!
May 5, 2016 at 18:49
Making node editablity baked-in is great, the developer shouldn't have to be listening for F2, etc. Of course it should also be possible to make the tree read-only. Would it possibly be useful have only certain nodes be editable? That could be handled with an event that lets the developer set a cancel flag.
May 5, 2016 at 19:20
Hi Jim,The tree will be read-only by default. Then you have to wire up something to tell us whether a specified node is capable of editing. That way you can have editing supported only on certain nodes if you like. For nodes that don't support editing, it will never even enter edit mode that way.
Bill Henning (Actipro)
May 5, 2016 at 20:38
That sounds great!
July 1, 2016 at 09:06
Actipro Blog 2016 Q2 Posting Summary
Actipro Blog 2016 Q2 Posting Summary
The Actipro Blog - WPF, WinRT XAML, Silverlight, and WinForms Development