|Date: ||Wed, 2 Feb 2005 09:27:33 -0500|
|Reply-To: ||"Richard A. DeVenezia" <radevenz@IX.NETCOM.COM>|
|Sender: ||"SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU>|
|From: ||"Richard A. DeVenezia" <radevenz@IX.NETCOM.COM>|
|Subject: ||Re: Example of a Event / Event Handling in AF|
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
> 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
* 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.;
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;
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,
There are many was they could process a message regarding a change in
environmental state (modelType,etc...)
- attribute linking, although linking to an ownerId attribute doesn't seem
possible from class editor->comp def->prop editor window. Might be possible
- 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
The beauty of lots of little things that respond to each other is the
emergent behavior that can arise.