Provide a native Treeview control
The Treeview control is an extremely powerful way to display related and hierarchical data in a nodal fashion. I have built application for years using the vb Treeview common control. These applications could not be successful without it. There is certain data such as a computer folder and file structure that would be nearly impossible to comprehend without it., However, the non native Treeview require serious knowledge of Access and VBA to use successfully. Also portability has always been a problem. A native control with some features that make binding data simpler (possibly a wizard), would really expand what the common user can do with Access.
We are actively looking at providing a native tree view control.
Please continue to vote and provide more info – scenarios, examples and requirements will all feed into our exploration.
Scott Wyant commented
I have an application that would be very similar in concept to the BOM comment below. I would like to allow users to select a group of similar components. The higher up in the tree, the more components returned. Lower down returns a shorter list but with stronger similarities.
First thank you for you very interesting comment.
Please bear in though, that while ideas in comments may make an individual pause for thought, they are not UserVoice entries in their own right so cannot be voted on, nor will the Access Team be able to find them easily if they do decide they're interesting and want to revisit.
As far as CTE enhancements go, bear in mind also that is part of ACE and not Access. I'm not even sure the Access Team have responsibility for ACE. They can correct me if I'm wrong but I believe they're simply a consumer of that technology.
Access itself is not able to handle hierarchical data like a BOM (Bill of Material) natively. But a lot of us are using SQL Server as backend which is able to use recursive queries. So the data is there but no way to display and work with it on Access side. You need to use a lot VBA to convert the data into a COM treeview control and it is not connected to the data so you need more VBA to edit it and to connect it to a separate form. The treeview control has also a lot of other disadvantages like the need to reference to the COM object which breaked at least two times with MS updates in the past leaving a lot of applications "dead" until the community found a solution and very late MS fixed the updates. Not to mention 64bit support and so on.
The thing is that Access already has a tree styled form natively implemented in the datasheet views since at least A2007 or earlier. But it is only limited to 7 levels, more are not possible. You can find an example of it on my download page http://www.ccedv.de/downloads/en in the file "AccessTreeView". So if that would be improved to unlimited levels and also to normal continous forms (the existing one only works with Datasheet views) it would be a great step forward.
As I needed a tree style normal continous form with the ability of displaying tree lines and RTF fields for multiple formatting options I made my own treeview classes using a normal continous form. This can edit the fields in the tree, can assign different styles and works with DAO/ADO and ADPs. You can also find that on my download page in the file "CCTableTreeV2". (It can be used by everyone for free.)
So if Access would provide a treeview form in the same way natively it would be a great step forward for all of us which are dependent on hierarchical data.
Further examples beside the above mentioned BOM: I use this tree to display a filter tree beside another subform. So in our warehouse application for example it shows a level for internal and external warehouse locations, if you expand that, all warehouses in one location, in there all storage places in a hierarchical structure like room/shelf/level/box and so on. Clicking on each node displays the filtered contents in the detail subform.
Another example can be a navigation tree to navigate through different application modules similar to the .NET known accordion controls.
Not to leave out the standard problem of displaying master and slave data like orders and order rows. This is possible with the [+] styled data sheets like mentioned in my first example, but unfortunately very problematic to use and also not very stable i.e. in split forms with more than one subform and so on.
The really great improvement for Access SQL would of course be to give us a CTE SELECT like SQL Server and more great if it also would provide recursive queries. That would be a consequent thought after having a treeview continous form.
There would then no need to implement a new treeview control like the COM treeview as the continous form could be used to simulate the same.
By the way: It would be great to implement a new event to the continous form which is able to return the current record where the mouse pointer is over. This would allow to program a simple drag and drop and lot of user useful things.
I´ve develop access applications (from 2003 to 2013) using MSCOMCTL.OCX with the tree view control......
It is very complicated to maintain the functionality througth diferent versions of WIN32 WIN64 with the references, system32/syswow64......
If Access had native tree control..... a ot of problems gone!!!!!!!
PLease please please let access be self-functional like the very good tools that it is and provide native tree view control....... a good control to enpower and consolidate access like programming tool!!!!
Mischa Haller commented
To create modern business applications, a modern and fast Treeview Control is absolutely necessary! It is unbelievable that MS Access in 2017 has no such control.
See at Klaus Oberdalhoffs post.. me too.. but a MS integrated solution would makes me happier...
Have a look at Exontrol.com's Grid control. It has lots of capabilities. We are using it, but not for tree view yet. It is expensive but has alot of customization.
Anders Ebro (TheSmileyCoder) commented
In response to the admin reply: "Please continue to vote and provide more info – scenarios, examples", I can demonstrate the 2 applications I have which have used the treeview extensively, should it be of any interest.
One is a requirements management tool (10.000 requirements) and as requirements are nested, it would have been extremely painfull to do this without a treeview.
The other is a review tool, which tracks documents, files, packages, and review comments across multiple versions, for a construction project in Central Copenhagen. It has currently reached 8000 document submittals, and has been running for 6 years. The treeview is used to display grouping of documents within packages, within areas. In a different form, the first treeview level shows document versions, second shows comment groupings, while the third level shows the comments themselves.
any update on this topic?
Last communication was about 3 months ago.
Any news getting a treeview that works with 64bit Access?
How soon is soon?
I too was hopeful that this will be implemented at some time and still am eager that the Access team will get around and provide a TV. It is a very basic feature to have in our day and age.
I understand that there are a couple of TV controls on the market. They are really great but:
1. One is currently free but the authors already claim that they have a beta version for a better one that will no longer be free. The other is quite expensive. I also tried the demo file they provide and it is buggy: clicking some of the nodes causes an error with a message claiming that there is no room for some sub-form and points to a vblr6.chm file and then crashes.
I realize that these can be dealt with by the authors (and I do have great respect and admiration for their coding abilities and expertise) but still, a native control will be fair after all this time, and will not require extra expenses from the Access community for such basic functionality.
2. Both do not have drag and drop capability at this time, which to me is very important, and is a game changer.
I hope you will reconsider and if I could I would have added my votes here but can no longer do so as this suggestion item has been closed
Klaus Oberdalhoff commented
a german company (picoware) sells VBA sourceCode - Free of any OCX and API (so also 64 bit with no problem) - a pure continuous subform which acts as a pure treeview. For the moment the docu is german only, but the head behind that idea is translating for the moment and an MVP-collegue showing it on the MVP summit ... www.picoware.de
I've bought it and use it and i'm overwhelmed and absolute happy.
I feel your frustration Mark.
I suspect they have to be careful with what they commit to in the current round though, as resources are always finite.
Mark Taylor commented
Just goes to show how out of touch the Access developer team is with the needs of its users.
This has already been proposed and is under review. Delete this suggestion and save your votes :-)
Create a new Treeview-Control with more Features, design and a better performance
I think this code is great. It comes as freely usable source code that anyone can include within their own projects.
However, I believe such functionality belongs within the product itself. As it can be used from Excel as well as Access, perhaps it should be included as an Office feature rather than limited solely to Access.
Consistency between projects is important and if each has a chance to implement this in their own different ways then how easy is that to take on for a third party?
There is a vast difference FMPOV between this as some published VBA and this as a feature provided by Microsoft and included within Office itself.
I truly do not understand this request as it has already been mentioned there exists a FREE (no strings attached), 100% VBA treeview which work in all versions and bitnesses.
What else do you guys need? Is there a problem with it? There are soooo many more important things that need to be fixed. This truly isn't an issue. It used to be, but thankfully someone took it upon themselves to fix it since MS wasn't doing it!
It would really nice if a TV control could load its images either from a table or from a folder and not another control (imagelist)