Drawing a Tree Structure

I’m working on an iOS mobile app that creates a tree and I wanted a way to display it. Searching online I found this excellent post on Rachel Lim’s Blog:

She provides source code for a demo program written in C#. I’ve converted it to Xojo and have got it working so I thought I’d share it. In the comments in the post there are some suggested changes with a link to revised source code but I didn’t get that version to work properly. But I have not tested this for a variety of tree structures yet.

The following Dropbox link contains a PDF of her post (in case it goes away, and her original source code (in case it goes away) and Xojo binary project which runs on an iPad in the simulator.


Nice, I like the way you did the Helper class, especially, and you separated the data from the view.

I’ve converted it to a Desktop app and am experimenting with it, will post a demo in a week or so which has selectable icons with drag’n’drop to re-arrange the tree.

Intuitive algorithm. Thank you for sharing your find. I think it will be useful in the future and for me!

1 Like

Thanks for sharing.

but please consider using a code hosting plattform like github for this. Your Dropbox might move away in some months or years. If you host your code publicly on Github it stays. This is always the better way imho.

1 Like

All the credit goes to Rachel, I just ported her code as exactly as I could figure out.

As a “citizen developer”, I’m not going to do things that aren’t fun for me. :wink:

My free Dropbox account has been dormant for years and I only use it for stuff like this so I don’t anticipate it going away for a long time.

Feel free to add it to your own depository and let us know.


Even as a hobbyist developer, I highly recommend to have a look at Github. For your personal use, but also if you‘re serious with sharing code with the community.

For most developers Github is the first address to have a look for open source code. Not a forum nor a private Dropbox.

1 Like

Have you incorporated Carlos’ bug fixes (in the comments)?

I tried, but they introduced problems. I’ve incorporated his 2nd one, the one that Rachel acknowledged. Have not tested with lots of examples yet, still working on my app.

Yes, implemented Carlos’ fixes and also the test tree Carlos provided. I have a desktop app working fine, just adding some bells & whistles so you can select a node, and drag & drop a subtree to change it graphically :slight_smile: Need to tidy it up and I will post an example next week.

It’s interesting to see the result. I look forward to demonstrating this improvement to the program.

Hi Kay (and anyone else), have a play with this…

At some point I will add a number of other tree representations as well - circular, Petri and more. I also think it might be worthy of inclusion in the Xojo Examples projects.

NB. Yes I appreciate the point of GitHub but given where I work I dare not use it.


My app has gotten to the point where I can test a lot of tree structures and, sure enough, you need all 3 of the suggested bug fixes.

I’ve donated my demo app to Xojo for future inclusion in the examples. It shows how to select nodes, drag & drop, expand/collapse branches, copy/paste/cut branches, and tree nodes can have more than 1 parent… also replaced much of the recursive functions with iteration (faster and more efficient on large trees).

1 Like

I’m curious as to how well it handles the following kind of “tree” where each pair of nodes at each level has the same two parents, and the same two children.

1 Like

Hi Robert, OK the way you drew that is resolved to a simply-connected tree. Your representation is based on each node being drawn once; in my demo the nodes are repeated under each parent; however note they are multiple instances of the same node, not clones. The downside is that a simply-connected tree grows very wide, very quickly (see example below). In some real-world finished apps, what they do is draw a branch completely the first time, then for subsequent instances of the same branch, the branch is compressed and only the root node shown, with a little symbol to indicate it is repeated elsewhere.

While it is possible to rejig the code to draw it your way (each node being drawn once), this rapidly gets ugly if you want to allow the user to copy/paste or worse, cut one of the parent links (but not remove the node completely) - you would have to select the line to be cut, to identify the single parent to be disconnected. It also gets really ugly if several nodes have a lot of parents.

For example (my day job is as an engineer) consider a complex product like a car (at the top of the tree, as node A). That is decomposed into subsystems, and so-on down to the unique parts in it. For example, Car has 4 wheel assemblies, and each wheel has 5 bolts and 5 washers… But what happens if the user decides he wants to make that a 3-wheeled car…

This was the point of having an Icon class (the icons drawn to the canvas, each icon having 1 parent) vs the actual data nodes (the Node class) which have multiple parents. By selecting an individual icon you can traverse up to find the specific parent, and cut it if you want to remove that parent.

Start with figure 1, copy & paste L under K, and M under J, this results in figure 2. Now copy K and paste under H, and copy J and paste under I; this results in figure 3.

Hi Nicholas. Thanks for the explanation. From the three diagrams that you’ve provided, I think you have illustrated how my incestuous tree will progress at each level. The number of nodes doubles with each level, whether going up or down. Depending on how you do your processing, this could be no problem at all, or it could run you out of memory, take hours to process, or both.

I ran into this a couple of years ago. My application wasn’t displaying the diagram. It was just doing calculations that were dependent on the parent nodes. It caught me by surprise when I found what appeared to be a simple network, with not very many nodes, taking hours to do the calculations. When I realized what was happening, I was able to fix the problem by checking whether a node had already been traversed.

(I’ve downloaded your demo, but I can’t run it at the moment. I’m on the road with my old laptop that’s running a pre-API2 version of Xojo.)

Easy enough to modify for API 1 … It did not take me long.


Hi Robert,

With a slight revision to make it recalculate the X-positions of compressed nodes, if it compresses the repeated nodes, the result looks like this, which is a lot better than when all the icons are expanded. Will post the project in a few mins.

NB I’m using Xojo 2021 Release 1.1.

I started to convert it to API1, but encountered a couple of things I didn’t immediately recognize, and was too lazy to sort it out. I have 2021r1 on my other machine. So, I can run it when I get back home.