Paul Walker wrote: >> Richard A. DeVenezia > > Thank you, the "self determining textbox" concept was very helpful. > > I am trying to build a fairly complex composite class with multiple > text boxes and a checkbox. I am able to make the textboxes "self > determining" with respect to the checkbox within the composite class > through the linking mechanism. However, I also want to make some of > the > textboxes "self determining" with respect to an attribute of the > composite class. That is, suppose I created an attribute on the > composite class named "Model Type". When I set the "Model Type" > attribute of the composite class to a given value, say "Logistic", I > want several textboxes within the composite to react by changing > their "visible" attribute > to "No". > > Any suggestions on how to approach this? Is it possible to easily > link the visible property of multiple textboxes within a composite to > a an attribute of the composite as a whole.

Easily link, I don't think so. Funny, the easiest in this case may be to externally dictate the appearance states. This would be accomplished in a setcam.

useclass myComposite.class; * useclass lets all attributes be utilized in code without _self_ referrent. * additionally, all composite controls are protected and thus their object * references are not (easily) availalble to code not in a useclass block.; .... setcamModelType: method attributeValue:update:char returns=num; * reset all composite controls to some initial state; ....

if attributeValue = 'Logistic' then do; * set relevant composite controls to their relevant states; textentry1.visible='Yes'; textentry3.visible='Yes'; pushbutton2.visible='Yes'; textentry5.visible='Yes'; end; endmethod; .... enduseclass;

If your ModelType has many values with an ensuing large number of distinct component control 'states' with respect to the visibility and types of component controls, then external management of the states can get tedious, error prone and overwhelming.

That is when you have the hard choice of staying with management via external control, or spending a fair amount of effort designing 'aware' classes to be used in the composite. These classes would be subclasses of text entry, push button, list box, etc...

There are many was they could process a message regarding a change in environmental state (modelType,etc...) - broadcast/receive - attribute linking, although linking to an ownerId attribute doesn't seem possible from class editor->comp def->prop editor window. Might be possible programmatically. - events and event handling -- this seems most feasible. The composite's setcamModelType would send a custom event to each of the component controls which would have an appropriate handler which would be loci of self determination. This modus operandi is quite similar to the model/viewer framework that is built into the SAS/AF root object "Object". Read more in SAS Guide to Applications Development (55888)

-- Richard A. DeVenezia http://www.devenezia.com/ The beauty of lots of little things that respond to each other is the emergent behavior that can arise.