Feedback by UserVoice

I suggest you ...

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.

500 votes
Sign in
or sign in with
  • facebook
  • google
    Password icon
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    MajP shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →


    Sign in
    or sign in with
    • facebook
    • google
      Password icon
      Signed in as (Sign out)
      • Anonymous commented  ·   ·  Flag as inappropriate

        On occasion, it has been commented that there is a free alternative to the Access TreeView.
        Welcome the contributions of people who altruistically dedicate their time and knowledge in providing help to others.
        However, the underlying problem here is that those of us who have invested hours in development with a tool that we already had in previous versions, we have to renounce it without further ado. A tool that in addition and in my view is the most powerful of Access in terms of displaying hierarchical data.
        We normal technicians do not even have to know about "native control" or non-native. In my opinion, it simply has to be provided.
        We simply assume and trust that each new version of Office, (and in this case Access), has at least the tools of the previous version.
        Best regards >> Jacinto Trillo

      • Peter commented  ·   ·  Flag as inappropriate

        Any news about that?

        I have used the 32 Bit Treeview for many years until I was forced trough external conditions to use Office in 64 Bit. And there ist still no treeview for 64 Bit for so many years.

        Scenarios? Displaying every kind of hierarchical data, i.e. Multi-Level-Structures of Bill of materials. Or Material-/Production/-Purchasing-Structures of ERP-Systems. Access/VBA w/o it is not half the worth.

      • Edgar Allen commented  ·   ·  Flag as inappropriate

        Sorry I posted this item. I just now see it was previously posted and Access development team is evaluating.

      • Edgar Allen commented  ·   ·  Flag as inappropriate

        Almost every other database development platform has a native treeview control. Access developers must use MSComctlLib.TreeCtrl.2 which only works with 32bit Office and is occasionally un-installed by an Office 365 update. Or, they purchase a third party activeX tree and worry about future compatibility issues.

        Visual Studio has its own treeview control as does Dynamics AX. Why is this control not included in Access?

        If you do decide to add it, I suggest it work like the Dynamics AX control which has somewhat better functionality than TreeCtrl.2. If that’s too much trouble, I’ll be happy with one just like TreeCtrl.2 if it’s native to Access.

      • L. Stuart commented  ·   ·  Flag as inappropriate

        A native tree-view control in Access would greatly help my admin staff to hierarchically organize project contacts.
        I have a requirement to put contacts into a hierarchical report based on the company the contact works for, the company’s role on a project, and the contact’s role within the company. By role I mean what responsibilities the contact and company have on a particular project. The hierarchy is not alphabetical, but based on specific roles.
        I’m currently using a crude system of forms to organize the roles, companies, and contacts which is difficult for the admin staff to use and prone to errors. Visio can be used to create organizational charts and generate reports, but few of my staff has access to Visio, nor the skills to use it properly. Using a tree-view form, preferably with “drag-and-drop” features to rearrange the tree, would be ideal for my end users.

        Best Regards.

      • Anonymous commented  ·   ·  Flag as inappropriate

        I agree. A native treeview would be a welcome, almost mandatory, addition to be consistent with expected user interfaces today. it's such a nice way to present a list of items to edit such that it's fast and obvious for the user to get to the one they want.

      • Scott Wyant commented  ·   ·  Flag as inappropriate

        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.

      • Adrian Bell (MVP) commented  ·   ·  Flag as inappropriate

        Hi Bitsqueezer.

        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.

      • Bitsqueezer commented  ·   ·  Flag as inappropriate

        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 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.

      • Pedro commented  ·   ·  Flag as inappropriate

        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  ·   ·  Flag as inappropriate

        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.

      • Anonymous commented  ·   ·  Flag as inappropriate

        See at Klaus Oberdalhoffs post.. me too.. but a MS integrated solution would makes me happier...

      • Yossi commented  ·   ·  Flag as inappropriate

        Have a look at'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  ·   ·  Flag as inappropriate

        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.

      • Gilad commented  ·   ·  Flag as inappropriate

        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

      ← Previous 1

      Feedback and Knowledge Base