Yes, I'd love to. Before that, lemme' tell you the basics of what I'm
trying to do. I'm using a "TEMP" table approach to data entry. This works
in our case for several reasons, but in no small part, because there is a
fixed number of records to enter (edit) and it doesn't change within a
project phase and only one field per row for the user to populate - there
would, in my estimation be far more challenges in trying do this w/ENTER
USING. I am also trying to avoid the use of var's at data entry (edit) and
all the hassles of making sure that the var would be assigned the correct
value as well as the underlying field/col.
Given this background, the EEP's are being developed to accomplish the
several functions, with the EEP shown below handling the task of processing
"SKIPs". IOW, some (subsequent) records may be skipped, if the input is
determined to trigger a skip (these are pre-defined, f/ex: if the input were
"MALE", or a code therefor, the rows/recs with inputs f/"FEMALES" would be
skipped). When a SKIP is triggered, a TARGET row is known, having been
pre-defined, and its val assigned to vSkipToVARName (here, a VAR is a
research study variable) and vSkipToStatus is set to ACTIVE, a 1. This EEP
is supposed to check for an ACTIVE status, then see if this is the target
field. If it is, then we're there, otherwise, SKIP this row and identify it
as having been skipped.
The following EEP worked fine w/6.5. The SKIP processing wasn't so tough,
but I was also trying to have the value defined for a SKIP be displayed in
the field as it was skipped, thus that code-sequence w/SET VAR
.../NEXTROW/UPDATE .../PREVROW/NEXTROW. This part ain't that speedy, but
it's based on an old legacy doc I found and I don't think it extend the
cycle-time for our users who perform the data entry (as a good developer, I
will be one of those users during acceptance testing).
I'll look fwd to your comments,
Steve in Memphis
Here is the EEP code :
--DEFieldEntry.FNP
--F/TEST Use the following line as necessary w/appropriate mod's/loc's
f/intra-process monitoring
--PAU 2 USI "Field Entry - TOP" CAPTION "EEP Testing & Feedback" AT CENTER
CENTER
--Check SkipStatus for 0-Inactive/1-Active
IF vSkipToStatus = (1) THEN
--Check if THIS is the TARGET VARName, To
IF vVARNameThis = (.vSkipToVARName) THEN
--It's a match, so de-activate SkipStatus & NULL-ify target VAR
SET VAR vSkipToStatus = 0
SET VAR vSkipToVARName = ""
ELSE
--Save this row
SAVEROW
--Get an identifier for this row, its having been saved
SET VAR vVARNameToUPDATE=(.vVARNameTHIS)
--Go to next row, briefly
NEXTROW
--UPDATE what is now the previous row
UPDATE +
RA_TEMP_LOADED +
SET +
ResponseInput = "-999" +
WHERE +
VARName=(.vVARNameToUPDATE)
--Go to PREVious ROW, its having been updated
-- This is for re-displaying the UPDATEd field-value
PREVROW
--Now, on to the NEXT ROW
NEXTROW
ENDIF
ENDIF
RETURN
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On
> Behalf Of A. Razzak Memon
> Sent: Thursday, March 14, 2002 10:26 AM
> To: [EMAIL PROTECTED]
> Subject: Re: EEP's Behaving "Erratically" After Upgrade to RBWIN6.5++
>
>
>
> Steve,
>
> Trust me, you and your clients will NEVER regret staying CURRENT
> and taking advantage of the latest and greatest versions of R:BASE!
>
> The BEST is yet to come ...
>
> Would you be kind enough to post the contents of your EEP?
>
> It will help everyone on this list to help you narrow down the boo-boos!
>
> Very Best Regards,
>
> Razzak.
>
>
> At 10:23 AM 3/14/2002 -0600, J. Stephen Wills wrote:
> >I hate to personify computer processing ("Behaving
> "Erratically""), but it's
> >okay here, as both y'all and myself know that such usage simply
> means that I
> >don't have the knowledge I need. Anyway, I had yesterday successfully
> >implemented 2 core sets of functionality by way of Field & Table EEP's in
> >the app I am currently developing, w/expected behavior being
> what actually
> >executed.
> >
> >So, my 6.5++ upgrade arrived yesterday and I, happily, but with
> >circumspection due all upgrades, installed it, both on my desktop and
> >laptop. Of course, the first little (stress) test I tried were my newly
> >coded and decently tested EEP's. Well, imagine my surprise and
> >consternation when these didn't behave as expected on either
> computer. So
> >far, based on my initial investigation into this, it seems to be
> a problem
> >in NEXTROW, PREVROW within a FieldEntry.FNP (EEP).
> >
> >Anybody have any ideas?
> >
> >Thanks,
> >Steve in Memphis
>
>
> ================================================
> TO SEE MESSAGE POSTING GUIDELINES:
> Send a plain text email to [EMAIL PROTECTED]
> In the message body, put just two words: INTRO rbase-l
> ================================================
> TO UNSUBSCRIBE: send a plain text email to [EMAIL PROTECTED]
> In the message body, put just two words: UNSUBSCRIBE rbase-l
> ================================================
> TO SEARCH ARCHIVES:
> http://www.mail-archive.com/rbase-l%40sonetmail.com/
>
================================================
TO SEE MESSAGE POSTING GUIDELINES:
Send a plain text email to [EMAIL PROTECTED]
In the message body, put just two words: INTRO rbase-l
================================================
TO UNSUBSCRIBE: send a plain text email to [EMAIL PROTECTED]
In the message body, put just two words: UNSUBSCRIBE rbase-l
================================================
TO SEARCH ARCHIVES:
http://www.mail-archive.com/rbase-l%40sonetmail.com/
