>> 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 sub-group. The problem, IMHO, is defining a rule (if any) to generalize grouping of objects. Thanks, regards Lucio _______________________________________________ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
