>> Each whole page is a group-derived object ; I keep a list of pointers
>> to these objects and jumping to another page is easy.
>> Just make the current group invisible and make visible another.
>> The redraw() caused by the bargraph goes to the current visible "page
>> group" ; a typical plant can have 20-30 different pages.

> OK: but my suggestion was that you have groups nested within groups, so that 
> the redraw's can be localised to just one specific sub-group...

Yes, it's right.
Now the configuration file is "flat" up to the page level, in the sense that 
it's divided in pages.
On each page I have buttons, images, etc.
Each page is a group, and all objects belong to the same group, logically at 
the same level
(Z-order is implicitely handled by the object declaration order ; it's not 
possible to overlap two animated objects).

I could introduce another level of detail, in the sense that the bargraph 
should be member of a small sub-group, containing the bargraph itself,
the background, etc.

Maybe this can be handled from the plant installer: Windows configuration 
software should handle "sub-objects" (recall the example of the station,
formed by the bargraph, a background, on button...) .
These sub-objects would be the ideal candidates to be in a sub-group, and could 
be then grouped at configuration-file level.
Without this information from the plant installer it's difficult to 
"generalize" : there could be one *big* tank image,
and 5-6 bargraphs over it, each one representing different things (level, 
temperatures, etc).
In this case the group is the whole tank and all the bargraphs...

On the other side: small tank, small background, one bargraph - the perfect 

The problem, IMHO, is defining a rule (if any) to generalize grouping of 



fltk mailing list

Reply via email to