dce@smsc.sony.com (David Elliott) (01/17/91)
There have been a number of cases where I would like to group a number of widgets based on purpose instead of on hierarchy, and address their resources as a group. For example, I have an application with a RowColumn widget holding with 6 pairs of labels. The first label in all the pairs is a title, and the second is a value. So, I'd like to be able to work with the titles as a group, the values as a group, and all the labels as a group. Now, it seems to me that the only correct way to do this is to create two subclasses of the label widget: titleLabel and valueLabel, and use these. Is there an easier way that doesn't cause problems? If not, it seems to me that having sample code that implements these trivial subclasses and allows one to give the name at compile time, or even at runtime if possible, would be very useful. I believe that this should be fairly easy for the Athena widgets, since their distribution isn't restricted, but Motif may be a hassle. Assuming that this is a good way to go, are people interested in seeing this done?
lynnes@ALEX.CSS.GOV (Christopher Lynnes) (01/18/91)
David Elliot writes: >There have been a number of cases where I would like to group a number >of widgets based on purpose instead of on hierarchy, and address their >resources as a group. For example, I have an application with a >RowColumn widget holding with 6 pairs of labels. The first label in >all the pairs is a title, and the second is a value. So, I'd like to >be able to work with the titles as a group, the values as a group, >and all the labels as a group. > >Now, it seems to me that the only correct way to do this is to >create two subclasses of the label widget: titleLabel and valueLabel, >and use these. Is there an easier way that doesn't cause problems? I don't know how correct the following solution is but it works and is fairly simple: (1) Give each title widget the same name (say, Title) and each value widget the same name (say, Value) (2) Put each Title-Value pair in its own RowColumn, and give each RowColumn a UNIQUE name (say, one, two, etc.) (3) Access the common Title and Value resources by Application*Title.resource: specification Application*Value.resource: specification (4) Access specific Title or value resources by specifying the parent as well Application*Parent.Title.resource: specification Below is a uil example with the X resources to produce two Title labels with different strings but the same color, and two Value labels with different strings but the same color: The Uil file: module TestUil version = 'v1.1' names = case_sensitive include file 'XmAppl.uil'; object main : XmRowColumn { controls { XmRowColumn one; XmRowColumn two; }; }; object one : XmRowColumn { controls { XmLabel Title; XmLabel Value; }; }; object two : XmRowColumn { controls { XmLabel Title; XmLabel Value; }; }; object Title : XmLabel {}; object Value : XmLabel {}; end module; The X resources: TestUil*one.Title.labelString: Title 1 TestUil*two.Title.labelString: Title 2 TestUil*one.Value.labelString: Value 1 TestUil*two.Value.labelString: Value 2 TestUil*Value.background: Red TestUil*Title.background: Green TestUil*one.orientation: HORIZONTAL TestUil*two.orientation: HORIZONTAL Hope this helps. Chris Lynnes ===== : = ::::: Teledyne Geotech ===== :: == ::::: Alexandria, Virginia ::: === (703) 739-7316 :: == lynnes@seismo.CSS.GOV : =