On Sat, 29 Jan 2005 17:31:11 -0500, Richard A. DeVenezia
<radevenz@IX.NETCOM.COM> wrote:

>Paul Walker wrote:
>> I am trying to understant Events and Event Handling in AF, and
>> wondered if anyone could help me in developing an example along the
>> following lines. I want to put objects checkbox1 and textentry1 on a
>> frame. I want to click on checkbox1 so that its selected attribute
>> becomes 'Yes', and this will trigger textentry1's text property to be
>> set to 'Hello'. I want to do this using Events and Event Handling.
>> Here is what I have so far.
>>
>> Created new event handler for textentry1:
>>
>> Event Generator: Checkbox1
>> Event Name: Selected Changed
>> Method Name: Hello
>> Enabled: Yes
>> Description: Runs the method Hello when the selected attribute of
>> checkbox1 changes
>>
>> Created new method for textentry1:
>>
>> Method Name: Hello
>> Source Entry: emonitor.easymonitor.testframeMethods.scl
>> Source Label: Hello
>> Signature: ()V
>> Enabled: Yes
>> Description: Method that is invoked when the selected changed event
>> occurs on checkbox1
>>
>> Created new SCL entry emonitor.easymonitor.testframeMethods.scl with
>> Hello method definition.
>>
>> Hello: public method;
>>
>> declare object textentry1;
>> _FRAME_._getWidget('textentry1',textentry1);
>>
>> textentry1.text = "Hello";
>>
>> endmethod;
>>
>>
>> I then compile the method followed by the frame. When I run and
>> click on checkbox1, I get the following error.
>>
>> ERROR: Invalid type signature (O) for method Hello.
>> ERROR: Call to Hello failed. Unable to send event selected changed to
>> Textentry1.
>>
>> Why do I get this error message?
>
>You get the error because when the event handling system calls the event
>handler it passes one argument of type Attribute Changed Event Class
(ACE).
>ACE tells you more about the thing that caused the event handler to run.
>
>Use the property editor to change the signature of the checkbox's Hello
>method. Add one input argument of type object.
>
>Your handler method should be changed to
>--------------
>declare sashelp.fsp.frame _frame_ = _frame_;
>
>hello:
>public method event:inputbject;
>
> put event.classId.description=;
>
> put event.objectId=; * object reference to the checkbox;
> put event.attributeName=;
> put event.value.characterValue=;
>
> put event.objectId.selected=;
>
> declare Object te;
> _frame_._getWidget ('textentry1', te);
> te.text = event.attributeName || "=" || event.value.characterValue;
>
>endmethod;
>--------------
>
>You might be wondering about event.value.characterValue. Well the value
>attribute of an ACE is something called a Type object. The Type object
>wraps the actual value of the attribute of the thing that was changed. If
>the attribte was a numeric one, you would reference it via
>event.value.numericValue. A Type object can also wrap a listValue or
>objectValue.
>
>Why all this wrapping ? Well in a generic abstracted event handling
system,
>the handler might be a foci of many instances of different things.
However,
>in your case, you have a very specific usage in mind, thus if you wanted
to
>you could go with go with event.objectId.selected instead.
>
>
>This approach begs analysis though. Is it sensible to specify the
checkbox
>to textentry linkage in an event handler ? I have mixed feelings. A
first
>approach might be to make the text entry responsive to a state change, as
>opposed to being the recipient of an external action forced upon it.
>Perhaps the difference is between centralized control and self
>determination.
>
>How would a self determining text box work.
>
>1. add a character attribute .hello to the text entry
>2. set .hello setcam method name to setcamHello (PE will create method
>setcamHello for you)
>3. link .hello to Checkbox1.selected
>
>Use this for the SCL
>--------------
>* a method to set text as a side effect of hello receiving a new value;
>setcamHello:
>protected method newValue:input:char return=num;
> if newValue = 'Yes' then _self_.text = 'Hello';
>endmethod;
>
>
>_self_=_self_;
>--------------
>
>Hightpoints/Differences
>- The event handler way knows more about the object causing the event.
The
>attribute is force fed a new value.
>- In the linking way, the source object is consumed by the internal AF
>linkage mechanism and an attribute is given a new value (anonymously) to
>consider and it must decide what it wants to do with it.
>
>Both are legitimate, right and good. Which you choose depends on you and
>the larger picture.
>
>You can find more AF examples at http://www.devenezia.com/downloads/sas/af
>
>--
>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.