graphical tree report generation (2000/sp3)

Topic

New Reply

Hello again, everyone.

I’ve come yet again to beg support from those far smarter than me.

I have a treeview control that I’ve been perfecting across several different databases, and it’s working very well. There is a table of node data, and a table of “other” data (varies database to database). The “other” table has references to the node in which each record applies. In the form, a left-hand column displays the treeview control, and the right-hand column displays referenced data from the “other” table, refreshed whenever a new node is selected.

All that’s fine and dandy, and working well. Now comes the tricky part — graphical representation generation. I’d like to actually have the tree drawn out with lines (similar in style to the treeview control itself), containing both node data as well as the “other” data referenced at the end of each tree branch. Ultimately I would like this output such that I could “print to PDF” or “publish to HTML” format. Either is acceptable, both options of course being preferrable.

Is anyone aware of any code or tools that I can use to help me in this challenge?

thanks!
..dane

Reply | Quote

Replies

I’m not sure what you hope to gain by doing this sort of thing. Treeviews are useful on forms as they let you quickly jump from one record to another on a form. We use them extensively on things we do – see our website for several examples – but we have never used them on a report. For one thing, there is no Can Grow or Can Shrink property for a treeview, and report controls typically need them. In that respect they are much like combo boxes or list boxes – we seldom use those on reports either. Another issue is that a treeview usually is one line which can be associated with a large quantity of data displayed in a form.

You may have some concrete ideas about how it would be useful in your situation, so I’m curious how you think they would help display your data.

Reply | Quote

Good question, Wendell.

It’s fairly simple, actually. I work in an electronics design area, and in this field there are many manufacturers that make the same part (resistors, for example). The decision, then, as to who to buy a resistor from comes from other areas of the design process (quality, puchasing [cost, availability, etc], etc). Additionally, this information changes regularly.

As a result, the actual electrical designers are continually having to ask who the ‘manufacturer of the day’ is for various part types, and I am trying to come up with an easy to use (and easy to maintain!) reference for the engineers.

I have an access database setup whereby puchasing/etc can update the preferred manufacturers for given part types (the part types being the nodes in the treeview control (resistors have sub-part types like sizes, power dissipation, etc. that may apply to the decision process). Once an end leaf is selected (a specific part type), then the “other” table is referenced for the ranked manufacturer list.

That’s all fine and dandy. The question is how to best put it in the hands of the engineers. Most of them don’t have (and don’t want) Access installed, so I need some easy-to-use method of getting the data out. Graphical representations are typically easiest to use, so I am imagining a fully-expanded tree, where each end leaf node then lists the ranked manufacturers list to its side… I could then publish this graphical list to a webpage, or to a PDF, and place it on the network for easy viewing access.

I should say here that I am currently using a slightly different approach, and that’s to recreate the tree and list structures using Javascript in HTML form. The user interface is much the same, but it is essentially in a “readonly” format (no buttons to change the data.. just the treeview control and a listbox off to the side). This method seems to be working so far (manually). Once completed, I will write the macro function within the access database to create the treeview and listbox definition structure information.

That of course is my current approach. Any easier mechanisms (that preserve both data management as well as data viewing) I am open to hearing about.

thanks!
..dane

Reply | Quote

Ah Ha! So you aren’t really looking at a report format. A TreeView can be very useful on a web page – the engineer doesn’t want to have to scroll through 200 pages to find the part number that needs to be specified or ordered. The problem with the Java Script approach on a web page where the code runs locally in the browser is that you have to pass all the data to the browser. What you want to do is to use the treeview to specify the data to be displayed and then display the part number the engineer selects. There are at least a couple of different web page controls that can be used to give the look and feel of a treeview. DBI Technologies has one that we use frequently in our projects. Also, there are .Net controls available that work in a similar fashion – the navigation controls on our web site use one of them. The Microsoft ActiveX control should in theory also be useable, but it has several constraints that we find rather limiting.

Reply | Quote

Thanks for the link to DBI, although on first glance it looks like pay-to-play software; unfortunately this tool is one of those “if the company’s not going to step up, I’ll do it myself,” so I don’t have any money to purchase tools with. I understand the limitation of having to send all the data to the browser, but that’s really not a big problem for me since it will be used within the intranet of our company (fast connections).

If you can point me to any free alternatives, I’d gladly take a closer look.

thanks!
..dane

Reply | Quote

Actually, you can download sample ActiveX controls from the DBI site – they will however give you NAG messages until you acquire a license. The major advantage of the DBI TreeView is speed. To load a three level 1000 first-level nodes in the Microsoft ActiveX control can take a cup of coffee on many PCs – and doing that to a browser will be even slower. The DBI control works rather differently, and we routinely load several thousand first-level nodes in a few seconds. So you may well be able to justify it on productivity comparisions.

Reply | Quote

Wow. That’s quite a difference. I’ll check them out more closely..

thanks!
..dane

Reply | Quote