# Virtual TreeView: a Delphi tree control built from the ground up > Virtual Treeview is a Delphi treeview control written from scratch, with many years of development behind it and a stated aim of improving on existing tree controls. It ships as a source package with demos, help and tests, supports RAD Studio 10 through 13 on the V8 line, and is published under a double MPL and LGPL licence. **JAM-Software/Virtual-TreeView** — Virtual Treeview is a Delphi treeview control - Repository: https://github.com/JAM-Software/Virtual-TreeView - Website: http://www.jam-software.de/virtual-treeview/ - Stars: 740 · Forks: 286 - Language: Pascal - License: not declared - Published: 2026-10-21 · Updated: 2026-10-21 · Language: en - Canonical page: https://hysenlabs.com/projects/jam-software-virtual-treeview ## What the control does and how it got here Virtual Treeview is a Delphi treeview control built from ground up. The README states that many years of development made it one of the most flexible and advanced tree controls available today, that it starts off with the claim to improve many aspects of existing solutions, and that it introduces some new technologies and principles which were not available before. That last clause is a claim about the design rather than the feature list, and it is the honest way to read a component that has been developed for a long time. A tree control that has been refined over many years accumulates behaviour that is hard to describe in a paragraph, which is why the README points at the demos, the help and the wiki rather than listing features. The project is not new. JAM Software took Virtual Treeview under its wing in 2014, and the README says not much will change besides the homepage and the download location. The current releases carry version 8.x tags, and the author for contributions is Joachim Marder, whose contact address is in the README. The primary language of the repository is Pascal, the topics are control, delphi, pascal, treeview and delphinuspackage, and the repository layout is that of a Delphi component: a Source/ directory, a Packages/ directory for the component packages, a Demos/ directory, a Doc/ directory, a Help/ directory for the help file, a Resources/ directory, a Tests/ directory, and the project files at the root, including a .groupproj and a .dspec for the distribution tool. ## Which version to download for which compiler The download section is a table of versions against compilers, and picking the wrong one is the main practical mistake here. V8 is the official release line, for RAD Studio 10 to 13, and it includes some breaking changes, with a wiki page linked for the details. V7.6.x is for Delphi XE3 to XE8, and it points at a specific tag, V7.6.6. Then the older and alternative lines. V5.5.3 covers Delphi 7 to XE2 and is available as a direct download of a ZIP. The V6 stable version is tested on Windows XP and 2003 support and is available as a GitHub archive. For installation instructions there is an INSTALL.TXT file in the ZIP, and Delphinus package manager support was added. The alternative ports are where the fork situation gets complicated. An experimental FireMonkey port lives at livius2/Virtual-TreeView. A port to Lazarus and FPC lives at salvadorbs/VirtualTreeView-Lazarus. And for a Delphi XE2 compatible fork there is a branch on Fr0sT-Brutal's VirtualTreeView_mod, in the fr0st_xe2 tree. So there are four distinct targets to reason about: the main Delphi line, an experimental FireMonkey port, a Lazarus and FPC port, and a community fork for an older compiler. Anyone evaluating this needs to decide first which of those they are in, because the API and the maintenance situation differ substantially between them. ## Building and running the unit tests The testing instructions come in two forms, from the IDE and from the command line, and the command line form is what a build server would use. From RAD Studio, you open the Tests project file, run the project, and use the --run command line option to run individual tests. ``` Open "Tests\Tests.dproj" ``` From the command line, the sequence needs the RAD Studio environment variables set first, then a console build of the test project, then the test executable. ```cmd RsVars.bat MsBuild.exe /property:Platform=Win64 /p:Config=Console Tests\Tests.dproj ``` ```cmd Tests\Tests.exe ``` The example for running a specific test suite passes the same --run switch, and the README shows a per-project test executable used that way. ```cmd Tests\ShellBrowser.Tests.exe --run: ``` The ShellBrowser name is worth a note, since it suggests the test suite is organised per functional area rather than as one lump, which matches the top level of the repository where a Tests/ directory sits next to the demos. The console build configuration is the detail to notice. A Delphi GUI unit test project normally opens a window, which does not work in a build server, so the project supports a Console configuration and the build script selects it with the Config property. That is a small thing that tells you the tests are meant to run unattended. ## How the project handles bugs, features and support The project has unusually explicit rules for all three, and they say more about the project's maturity than a changelog would. On bugs, the first instruction is to make sure you are using the latest official version. When reporting a bug you should attach a sample project as a ZIP file that allows quick reproduction, and that can be one of the demo projects modified to show the bug. If only small changes are required, a description of how a demo project needs to be changed to replicate the bug is sufficient. If you already have a solution, supply a patch file or make a pull request, and if you used a previous version that did not have the bug, include that version number. On features, the focus is currently on reducing the number of reported bugs and getting Virtual Treeview stable. Feature requests will most likely not be processed at the moment, and the project says it will only process enhancement requests if the new feature is of general interest and a source code patch based on the latest SVN revision is attached, marked with the Enhancement flag. Requiring a patch for an enhancement is an unusual policy and it says clearly what the maintainer's capacity is. On support, the README asks people not to contact the developers or JAM Software for technical support, and points to the community instead: Stack Overflow, Delphi Pages, Delphi Praxis and the Embarcadero forums. The issue tracker is for true bugs only. The README also has a specific appeal for help, and it is a maintenance gap rather than a feature request: any volunteer who takes care of C++ Builder bugs and packages. The author does not use C++ Builder and has very limited experience with it, which makes it difficult to handle the bugs reported against it and to maintain the C++ Builder packages. That single paragraph is the most useful signal for an adopter, because it tells you exactly which part of the component is under-maintained and which parts are not. ## Where Virtual Treeview is the wrong choice The first limitation is the compiler floor on the current line. V8 requires RAD Studio 10 to 13, and V7.6.x is the line for Delphi XE3 to XE8. The older lines are still there, V5.5.3 for Delphi 7 to XE2 and the V6 stable build for Windows XP and 2003, but choosing them means choosing a component that receives no new development, and the V6 line in particular is a frozen artefact of an era when the operating system was the constraint rather than the compiler. The second is the platform story. This repository is VCL, and the FireMonkey port is described as experimental and lives in someone else's repository, as does the Lazarus and FPC port. So a team on FireMonkey or on Free Pascal is depending on a third-party fork's maintenance schedule, not on the upstream one. The third is the feature pipeline. The project is explicitly prioritising bug reduction over new features, and an enhancement is likely to be processed only if it comes with a patch. That is fine for an established control that already does what you need, and it is a problem for a team that needs something the control does not do yet. The fourth is the C++ Builder gap, described above. If you develop in C++ Builder, the part of the package you are most likely to hit bugs in is the part the author says he cannot support well. The fifth is the support channel. There is no direct support from the maintainers, and the guidance is to ask the community. For a commercial application with a deadline, that is a real consideration, because the fastest route to an answer is a question on a forum rather than a ticket. ## Licence, maintenance and the cost of a mature component The licence is a double one, MPL 1.1 and LGPL 2.1 with static linking exception, described in the README with a link to the modified LGPL description on the Free Pascal wiki. The GitHub shows the licence field as one it cannot classify, which is a hosting artefact rather than an absence of terms. A dual MPL and LGPL grant is a good fit for a component, and the static linking exception matters in practice, because a Delphi application links statically by default and the exception is what makes that legally comfortable for a commercial product. The repository is not archived and the last push was on 2026-10-12, so the control is actively worked on. The release history shows V8.5 on 2026-10-02, V8.4.1 in July 2026 and V8.4 in June 2026, so the V8 line is receiving steady maintenance, and the last push being later than the newest release means there is unreleased work in the tree as well. The cost of adopting this control is not the licence and not the money. It is that you are adopting a component with a long history, which means a long history of behaviour. A control that has been refined for many years has accumulated options, quirks and documented edge cases, and the documentation for that is the Help/ directory, the wiki and the demos rather than a single reference page. That is a genuine cost when you are evaluating whether a feature behaves the way you need, and the demos are where the answer usually is. The other cost is the toolchain. Building and testing the control itself needs RAD Studio with its command line environment, the RsVars.bat setup and MsBuild, so contributing to it means having the Embarcadero toolchain installed, which is the same constraint that applies to any Delphi component project. ## Conclusion Virtual Treeview suits a Delphi or C++ Builder team that needs a tree control with more flexibility than the built-in one, since the control is maintained with releases, demos and a test suite rather than being a one-off component. It does not suit a project that needs FireMonkey or Lazarus support in this repository, since both are ports maintained elsewhere. Check the breaking changes list for V8 before upgrading from V7, and expect the V8 line to require RAD Studio 10 or newer. ## FAQ ### Which version of Virtual Treeview should I download? The V8 official release supports RAD Studio 10 to 13 and includes breaking changes. V7.6.x is for Delphi XE3 to XE8, V5.5.3 covers Delphi 7 to XE2, and the V6 stable version is tested on Windows XP and 2003 support. There is also a wiki page listing the breaking changes in V8. ### Is Virtual Treeview available for FireMonkey or Lazarus? Not in this repository. An experimental FireMonkey port is maintained at livius2/Virtual-TreeView, and a Lazarus and FPC port at salvadorbs/VirtualTreeView-Lazarus. A Delphi XE2 compatible fork exists as a branch on Fr0sT-Brutal's VirtualTreeView_mod. ### How do I build and run the Virtual Treeview unit tests from the command line? Run RsVars.bat to set the RAD Studio environment, then build the console configuration with MsBuild.exe using the property Platform=Win64 and the config Console on the Tests project, and run the resulting Tests\Tests.exe. Individual test suites can be run the same way with the --run switch, for example Tests\ShellBrowser.Tests.exe --run:. ### What licence is Virtual Treeview published under? A double licence of MPL 1.1 and LGPL 2.1 with a static linking exception, which the README describes as described in the modified LGPL text on the Free Pascal wiki. The dual grant and the linking exception are what make it usable in a statically linked commercial Delphi application. ## Sources - [Issues](https://github.com/JAM-Software/Virtual-TreeView/issues) - [JAM-Software/Virtual-TreeView on GitHub](https://github.com/JAM-Software/Virtual-TreeView) - [Project website](http://www.jam-software.de/virtual-treeview/) - [README](https://github.com/JAM-Software/Virtual-TreeView/blob/master/README.md) - [Releases](https://github.com/JAM-Software/Virtual-TreeView/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/jam-software-virtual-treeview