Re: [Fxruby-users] FXTreeLists....

[Lyle J. <jl...@cf...>]

Hugh Sasse Staff Elec Eng wrote:

> Looking at the examples for FXTreeLists, there are some things that
> stand out.
> 
> Firstly, an item in an FXTreeList is not an FXTreeList, but an
> FXTreeItem. This seems contrary to customary computer science
> practice where trees and operations on them are defined recursively.
> I suspect that knowing why they are designed differently will help
> me understand them better, so if this design has positive benefits
> I'd be interested in hearing about them.

It is important not to confuse the FXTreeList widget with a "tree" 
abstract data type.

Every widget in FOX is some kind of window, and FXTreeList must thus be 
a window as well. But it wouldn't make sense for the FXTreeList widget 
to have other widgets (windows) as its children, and that's why the 
FXTreeItem class exists. FXTreeItem is a kind of data object (i.e. it is 
*not* a widget) that the FXTreeList manipulates, and FXTreeItem objects 
have most of the "structural" properties that I think you'd expect to 
see in a tree data type.

> Secondly, FXTreeLists allow you to add an item below another item,
> and supply "data", defined as "user data" with the object.  This
> data can be any Ruby object, can it?

Yes, right. This makes it more convenient to attach some 
application-specific data to a tree item, in situations when subclassing 
FXTreeItem would be overkill.

> The examples of use with
> FXTreeList seem to use a pre-constructed data structure in parallel
> with the FXTreeList, but this would seem to suggest I can use the
> FXTreeList to structure auxilliary data if I wish, without having to
> have two data structures to keep in synch.  Is that correct?

Yes, that's also true.

> Thirdly, once I start manipulating the data held in each FXTreeItem,
> if I wish to expand items below it for example, FXTreeItem doesn't
> seem to have a reference to its tree, only its immediate parent, but
> modifications to the tree structure don't take place at that level.
> how is this sort of thing normally handled?

I think most people just hang on to a reference to the tree list 
somewhere else in the application (e.g. as member data in the main 
window class, or whatever). For that matter, I don't suppose there's a 
problem with sticking a reference to the tree list in that bundle of 
user data that you attach to the tree items.