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.
here you find a working solution for a native Treeview:
My critical Access app needs a native tree control badly! And now!
An example.... A principal form (control panel) with menus and sub-menus and all the menu-nodes represented via tree view control.
Matty Brown commented
This feature is now urgently needed, since in the latest Monthly build of Access, if you open a form containing MSComctlLib.TreeCtrl.2, your application will crash!! It's been like this for a few weeks now, since at least 16.0.11727.20188. Any plans to fix this in the next Monthly channel build, and/or introduce the new native TreeView control?
Robert Self commented
A native Access TreeView/GridTree can be used for Accounting (progressive chart of accounts); Assemblies (Personnel groupings or major equipment groups having multiple sub-major components, i.e. refinery/hydro-carbon plant with Towers/Vessels/Tanks, each having exchangers, safety valves, smaller tanks, piping, electrical sensors, etc. Each with it own Unique Serial Number. Each piece of equipment may be moved in/out of service);
At each roll-up level each displayed, column should have specific display options available
1. Node.Key should accept a cStr(<Long>) without any leading character, thereby allowing for a simple reference to other form components - i.e. sub-form
2. Date columns should have option of Earliest (MIN), Latest (MAX), or "Average".
3. Number columns have option of Min/Max/Average/Total//None (display no 'summary' data)
4. Text columns should have option of DISPLAY NOTHING or Count
5. Boolean columns (or any text column) with the SAME value in EVERY sub-level should have option of show "SINGLE value"
6. grouping may be performed from "native" table fields or from joined tables-field (i.e. comboBox lookup data). An example would be a "List" table with each record having attributes (from 0 to multiple) using the List.Primary_Key and the Intermediate table referencing a series of Child.Foreign_Key References.
List.ItemOne -> Intermediate.Code1 => Value.Text1
Intermediate.Code18 => Value.Text_AAA
Intermediate.Code21 => Value.Text_CCDF
List.ItemTwo -> Intermediate.Code1 => Value.Text1
Additional Tree Functionality:
A, Drag/Drop (within same tree / to another tree)
B. Tri-State check box,
c. Full row highlight,
D. User provided Node Icons
E. Ability to allow Direct data edit
a treeview for all office applications
The same for imageview.ocx
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
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.
This is so needed. Example asset tree data.
Edgar Allen commented
Sorry I posted this item. I just now see it was previously posted and Access development team is evaluating.
Edgar Allen commented
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
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.
Antonio Salvá commented
I also agree. TreeView and ListView are powerful controls.
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
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
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...