TreeViewItem ... component or paint?

[haydxn]

When i was having problems with the PopupMenu, i thought it may have been down to not using individual components for my TreeView. I changed from using the paint functions to having a dedicated Component be created, and having that paint itself the usual way.

Now that i know the PopupMenu itself was at fault, do you think it would be better for me to go back to the paint method (and have the item itself be responsible for creating the PopupMenu etc… rather than a component) or are there other problems i may face?

My DataBrowser component (the source of which i’ll be posting once i’ve tackled this issue) displays subclasses of a BrowsableData type. My original system gave the paint functions to this type, which had a default implementation using a nice theme, with the option to display various fields on it. These were virtual so you could set the way it will be displayed directly in your data type’s definition, with the alternative option of creating a special component for a specific type of browsable data.

I changed it to use a BrowserItemComponent instead, and when i did this the debug build was a lot slower at scrolling - presumably from debug stuff carried out when handling many components.

Is it actually better to just use the item’s paint functions by default? Or is there really no issue here?

[jules]

I’d say that using the paint method is easier if you’re doing something basic with just mouse-click detection. The component method’s only really an advantage if you need to embed other components in the tree, or if you need more complicated mouse-event handling. If you’re doing lots of different types of data viewers then the component type sounds like a better bet to me.

[haydxn]

well this is what it looks like:

the BrowsableData base class has a built-in paint scheme that draws the blocks, and also adds any ‘fields’ to be displayed; these can be assigned with a ‘void setBrowserFieldNames(const StringArray& names)’ function in the constructor, and a ‘String getBrowserFieldText(int index)’ virtual function. I’ve given it two paint routines, both of which are virtual; the first paints the whole block with the name on the left, the second paints in the field area to the right of the name and dotted line. If you want the data to display something different to fields but keep the basic look, just override the second one. If you want a totally different look, override the first one. I think it’s quite flexible and also easy to use.

I’ve decided to just go for the paint method. The items only really need to have basic click functionality, and there’s also the option of putting a custom component in instead by overriding the createItemComponent function in the data class (which is called by the item object, and defaults to returning 0). The right-hand ‘editor display’ panel takes away most need for it though, showing a custom editor component (one of course designed for each data type) on top of the colour-coded and named display panel (the paint function and the display panel both take the name and colour details from the data object).

Obviously i don’t want to have too much browser-specific stuff lurking in the data classes, so it’s just a few virtual functions to define, a name string and some colours. Once that’s added to the data types in the structure though, it’s compatible with the browser.

If this strikes you as a stupid way of doing things, let me know!

[jules]

Sounds very sensible to me!