Date:         Fri, 15 Mar 2002 13:51:25 -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>
Organization: MindSpring Enterprises
Subject:      Re: Model SCL Labelled Sections
Content-Type: text/plain;

"Deborah Testa" <dtesta@sevenofninesystems.com> wrote in message
news:a6t54o$kgo$1@slb5.atl.mindspring.net...
> Hello,
>
> I'm trying to find a way to make repetitive model SCL code less
repetitive.
> I have the same error-checking code (checking for missing values and
> reporting them to the user) for several variables.  The model SCL looks
> something like this:
>
> Var1:
>   _self_._errorOffColumn('Var1');
> return;
>
> Var2:
>   _self_._errorOffColumn('Var2');
> return;
>
> Some sections get a little more complicated, so I'd like to be able to
use a
> structure like this:
>
> Var1:
> Var2:
>   SCL code here;
> return;
>
> Is there a way to know whether Var1 or Var2 caused the code to execute?
I
> can see the potential for saving myself a lot of coding time, but I'm not
> sure how to implement it.
>
> Thanks,
>
> Deborah
>

Deborah:

You pose an interesting question.  I presume you are using a form viewer
and not a table viewer.

As most AF developers know, in a _FRAME_, this type of processing is
commonly done and the 'applicable object' is determined using
_frame_._getCurrentWidget().

The same is almost true for the form viewer.  There is a form viewer method
_getCurrentComponentDetails() which can return the widget id.

Try this model scl .

dfinit:
  dcl list infolist={};
return;

dfterm:
  rc = dellist (infolist);
return;

var1:
var2:
  _viewer_._getCurrentComponentDetails (infolist);
  call putlist (infolist);
return;


This model scl however will _not_ work in the following scenario:
- enter value in var1
- press TAB
- enter value for var2
- press ENTER.

The labelled sections will run twice, but will report the same component as
current each time.

The TAB is not 'caught' as an event, so the model scl does not run when
sale1 loses focus.  The ENTER causes all modified fields to run their
object label. (Note: this same problematic behaviour occurs in frames too.)

I can't think of an obvious or easy way to handle the TAB situation.  The
SAS Institute implementation of Form Viewer Control controls how flow
control is dispatched to the labelled sections in the model SCL.  It may be
just something we have to live with.

A more robust templated/parameterized common code situation would be

var1: component=var1; goto varCommon;
var2: component=var2; goto varCommon;
varCommon:
  ...
  do common things to <component>
  ...
return;

--
Richard A. DeVenezia
Need long HTML Titles and Footnotes ?
http://www.devenezia.com/downloads/sas/macros/index.html#js