Tree View?

I am brand new to ID FactoryPMI. It is fairly straightforward to generate graphics and other things, but I really need a tree view for my site. So far, I have been unable to find anything whatsoever.

Given that the Designer relies heavily on a tree view for structuring the project, it seems there must be some way to do this.

Any suggestions or ideas are welcome, as well as alternatives.


As of now the Runtime menu is our one way of achieving a true tree structure in the runtime. We do not currently have a tree component.

I know of several projects where a “drill down” effect is achieved using several tables and Jython scripts to connect them. It works particularly well if you have 2 or 3 defined “levels” - beyond that you would want to separate the screens and pass parameters.

The screenshot I included uses a screen not shown to select a production run for a user specified date range. The displayed screen shows all downtime for that production run grouped by device on the top table, then individual events by device (for the selected device) on the bottom table.

What exactly are you trying to accomplish? Navigation and several other tree type examples work well as a runtime menu. If you’re trying to browse the local computer to get a file, you can use the Jython function, fpmi.file.openFile(), which also opens a tree type file browser.

Peering into our development schedule, a tree component is among the feature request list. Also included are tabbed controls, collapsible or scrollable containers, and an “Easy Table” that allows simple editing of data without entering SQL. We’re probably looking at the Fall or so, as we have all resources busily developing SQLTags, a nice dissectable sample project, more industrial components, more fundamental (vector based) objects, and object moving and (non-layout based) resizing. We welcome feature requests here.

Maybe a bit about the application is in order. We have identical equipment that is arranged geographically. The tree view concept can be used to drill down to a specific piece of equipment quickly. In our instance it would look a bit like:

city -> organization -> site -> gizmo1

Database structure is fairly simple. Each table represents a different piece of equipment. Tags would be (gizmonum.point), where (gizmonum) is the name of the table, and (point) is the column. Treeview would just be a mechanism to select the correct table number.

Lists are out, as we are designing to scale into the thousands.

If there might be a better solution than tree view, I’m wide open to suggestions.


I think a tree view would be the ideal component for what you’re describing. In this case, the runtime menu would be a poor choice because you have to manually build each entry. Thousands of objects in a tree hierarchy calls for a setup that will be dynamically defined by the database. We can visualize your data well without a tree, but the bigger red flag that goes off is about your data structure.

See this post about static versus dynamic schema layout, keeping in mind that a static schema is what you’re looking for. Also worth mentioning, our next upcoming feature, SQLTags, will do all the behind the scenes static schema database layout for you.

You’ll want to create the following tables: cities, organizations, sites, and equipment. You’ll probably want each piece of equipment to be a separate row in the table. If you introduce equipment of different types of equipment, create new tables by type. Make sure to add a column that points to their site. You’re going to want to make your data “taller” as opposed to “wider” for templatability. The more you expect the data at a given level to change, the more important it is to go with a rigid, static schema type approach. Ie, you’ll have 1000s of gizmos so they should be rows, but if you only have 3 cities you could work that in the designer and it wouldn’t be a big deal to manually add a 4th.

Getting back to a tree view, I can think of 2 obvious ways to populate it. The best would be with nice, static relational tables. Once you got it configured it would be entirely self defining from the database. The next best way is with a text path ie (c:\downloads\temp). In any case, the less predefined the structure is in your tables, the more you’ll necessarily have to manually make up for it when: creating, adding, or modifying your project.

I’ll post back with a few screenshots on how you could represent the data. For scalability, you’ll want to focus on the underlying data rather than what it looks like on the screen.

Just to add my 2 cents here…

First of all, Nathan’s remarks about database table structure are 100% on the money - definately do not have a table per piece of equipment. Databases like to scale in one “dimension” - rows. Not columns or tables. When you start scaling in any other dimension you will be fighting both performance and the design intent of the SQL language.

Second, I just want to say that the only reason that FactoryPMI doesn’t yet have a tree view component is the underlying theme of this thread: how is hierarchical data best, or most commonly, represented in a relational database? That is to say, our users want a tree view, but exactly how do they expect the tree’s data to be populated? Furthermore, what is the purpose of the tree view? To expose the selected leaf node? To expose the selected path? To execute a script action on double click of a leaf node? What about multiple selection? I imagine that there are very good cases for all of these uses, so the challenge for us is to figure out a consistent way to support all of these actions.

As always - we welcome suggestions!

Oh, and one more thing: since your heirarchy only has 4 levels, you could cleanly represent this using 4 lists: 1st list has all the cities, when you select a city, the second list fills in with that city’s organizations, when you select an organization, 3rd list fills in with that organization’s sites, etc. Not as visually pleasing as a tree, but it would scale nicely.

Carl gets the points for the alternative. Not as pleasing as the tree view, but the drop downs represent a very effective solution.

On to the comments on scalability. We intend to log data for 15 to 20 years. On the “tall” portion, it’s not tall now, but it will be.

Given MySQL replication and clustering, plus FPMI’s ability to define multiple data sources, I certainly wasn’t planning on the databases being on one machine. This is how I planned on addressing the “wide” portion.

Thanks for all the great comments, and this is a fantastic start.


Here’s a screenshot of using dropdown lists to achieve a “level” or “layered” effect. When you select a different city, it updates the options of the 3 below. If you select a different Organization, it updates the 2 below.

You would more likely specify the city and organization elsewhere, but you get the idea.

To address your comments above, this model scales well with additional databases. Usually that 1st layer, city, would be a separate FactoryPMI machine and you would use the retargeting feature to allow clients to connect to these remote projects, running them locally without even needing to know any network info about the server.

I had a need for a tree control, and cascading lists or a table just won’t do it justice. It’s for an index of terms found in a text, with links for each term. For instance, let’s say you ripped through a book with a dozen chapters, made a list of unique words, and kept a list of chapters they occured in. So, if I did this using a dictionary, I would have something like

TermsDict = {‘House’: [‘1’,‘7’,9’], ‘Dog’: [‘3’,‘4’,‘12’]} .

If I had a tree control component, I could populate the “parent” data with the keys, and the “child” variables with the values. But since there is no tree control, I took a stab at it using an html definition list. Basically, I take a dictionary, write the keys to the html doc as a list, and then keep track of which items were “activated”. If one is activated, I expand the list; if it was already expanded, I collapse it.

Could you take a look at the attached window and give me a reality check? This should work ok, right (my child items will also have links that do something)? I also tried it using the

  • tags, but they included some annoying bullets that I couldn’t get rid of, although I think it would be possible to get rid of them with style sheets. But since I don’t need a lot of nesting and I am not up to speed with CSS yet, the definition list seemed to do the trick. The only thing I can’t do with it is arrow-down through the list, but this will get me by.

    Also, is there any way to create a true tree control using the java libraries? Or would that be something you needed to enable in FPMI to get it to work at all?
    Tree.fwin (7.92 KB)

Wow! :open_mouth: clever! It sounds like a tree component would be in order.

Are you building your dictionary from a database? As I recall, our biggest issue with the tree was coming up with an intuitive way to populate data. Please provide feedback on how it would be useful to you. Here’s what I can come up with:

  1. Population by dictionary. Makes sense, but I think you would be the only person to use it since it has to be done in script.

  2. One data table. The user defines a key column. A parent column tells the tree where to place nodes. Optional pre-defined column names would perform special functions such as:
    _font: bold, italicized
    _order: (int) overrides alphabetical ordering with peer nodes
    _image_path: (string) 16x16 node icon
    _double_click: (string) Python code to perform

  3. Multiple tables, representing levels in the tree.

In this particular case, I am building the dictionary by analyzing a text file, but in another case it will be from a SQL query across several tables where I aggregate data. I used a dictionary mainly because I like them, but I could use anything else too. Besides, I like scripting. :slight_smile:

Maybe a wizard could be used for defining the data- first, define a binding for the parent items, and then a binding for the child items while using the result from the paranet binding, and so on. I can imagine that would remove scripting in many cases. For instance, to represent the kids in a school and all the classes they took, then the “parent” query would be something like “select grades from elem_school”. The child query would be be “select name from students where grade = ‘{parent_item}’”. The next child query could be 'select subject from classes where student = ‘{previous_child}’" and so forth.

If I had my druthers, my optimal tree control would be similar to the tree in the wXPython demo. Being able to define properties such as font, color, and icons really helps when dealing with a lot of items.

I know this is not going to meet all of your needs but this is what I have done.
I am using the row selector from the reporting plugin. I create my data in the query to include any sorting parameters required. I also have the parent and key columns leftover from the VB app and tree control I am replacing.

Once this is done I configure the filters in the customizer. This is very limited since the filters have to be defined at design time (I have a feature request in to expose the filters dataset). Also, at run time you do not have node access. The data out is about the only thing usefull for this. For my needs I have the user drill down until a single item is selected. I use an expression to keep track of the length of data out. When length = 1 I use parent and key columns to determine which node is selected and use these in other queries.

Oh, I liked your solution but I am not that good at python yet.

FYI - A true tree view component is definately on the drawing board.

I’ve been working on another solution until a real tree control is ready, and thought I’d share. See attached.

The problem with the html window solution above is that it became a bit sluggish if the number of items was very large. It also became a pain to control the scrolling after an item was selected.

So, I did it with a list instead, and use html to decorate the items. I suppose it would work fine without html too, but setting the fonts and colors give the items a more of a parent/child feel, plus by adding event codes in an href, different events could be fired based on item properties.

Push the Intialize button to set the global dictionary of items. Clicking on an item will expand/contract that item, the left arrow will collapse it, and the right arrow will expand it. It would be trivial to add events for “collapse all” and “expand all”. It seems quick enough up to 10000 total parent/child items, and is still reasonable at 30000 items. Hope someone can use it.
Tree.fwin (17 KB)