A couple of questions

[nmorgan]

I tried a couple of new (to me) things yesterday and I'm not sure I'm doing them right.  One appears to be working and the other is definitely not.

First, I used linked screens.  The application is a workers comp accident/injury report.  The data is such that if you fill out any of it, you are going to fill out nearly all of it.  I wasn't sure whether I should have "Write record" set to Y on all of them, just the first one or just the last.  Right now I have it on all 4 in the set and it seems to work.

Second, I have 6 pop-up screens that may or may not appear depending on the response to Y/N fields on the one of the 4 linked screens.  For example, the main form will ask if there was a witness to the accident.  The Y/N field has a process after slot that contains P:(IF @VALUE="Y" THEN EXEC "I*ACCIDENT*WITNESS").  The WITNESS screen pops up right on cue, but does not seem to be updating the record.  I have tried it with and without the Write Record parameter and with and without the F2 Save/G:U function key. No combination seems to work.

I did notice in the documentation that linked screens must all share a common border.  The 4 actual linked screens do so, but the pop-ups are smaller and of varying sizes.  Could that be my problem? 

Can someone give me a gentle push, or even a brutal kick, in the right direction?

[nmorgan]

Figured it out.  I forgot to put the S in options on the /PD.I screen for the pop-ups.  Once I did that they worked fine.

[precisonline]

First, I used linked screens.  The application is a workers comp accident/injury report.  The data is such that if you fill out any of it, you are going to fill out nearly all of it.  I wasn't sure whether I should have "Write record" set to Y on all of them, just the first one or just the last.  Right now I have it on all 4 in the set and it seems to work.

I believe you only need Write Record = "Y" on the last of the series.

Second, I have 6 pop-up screens that may or may not appear depending on the response to Y/N fields on the one of the 4 linked screens.  For example, the main form will ask if there was a witness to the accident.  The Y/N field has a process after slot that contains P:(IF @VALUE="Y" THEN EXEC "I*ACCIDENT*WITNESS").  The WITNESS screen pops up right on cue, but does not seem to be updating the record.  I have tried it with and without the Write Record parameter and with and without the F2 Save/G:U function key. No combination seems to work.

There are several things that work together to make a subscreen work.  It sounds like you need the "S" option on the /PD.I for the subscreen process.  Otherwise, the subscreen runs in its own memory space and doesn't update the main screen's record.

I did notice in the documentation that linked screens must all share a common border.  The 4 actual linked screens do so, but the pop-ups are smaller and of varying sizes.  Could that be my problem? 

Not likely.  Linked screens will all run in the same window, but popups don't have that limitation.  Interesting that you chose linked screens for this - not that it's bad, but an interesting choice.  What was the deciding factor that made linked screens work best?

[nmorgan]

Interesting that you chose linked screens for this - not that it's bad, but an interesting choice.  What was the deciding factor that made linked screens work best?

There is too much data for one screen, yet it is pretty much an "all or nothing" situation.  If you enter any part of it, you pretty much have to enter all of it.  I did discover that when revisiting an existing record, you can use PgUp and PgDn to flip through the linked screens, so it is not as cumbersome as I first feared.

I did find it slightly annoying that you cannot have a field validation on a multi-valued text field if you use INVOKE.TEXT.ED in the Process Before Field slot.  There are several such fields on these screens.  Is there any other way to make a field automatically word-wrap on entry is there, other than INVOKE.TEXT.ED?

[precisonline]

Word wrap, no.  INVOKE.TEXT.ED is "it".  You can use a negative field length in which case it'll break at that point, but not word wrap.  Interesting that you need both, however.  Why would you have a validation on a word-wrapped field?

[Tom Pellitieri]

Norman,

Regarding multi-value validation, you might want to review this SB.VALIDATE Thread

--Tom

[nmorgan]

Why would you have a validation on a word-wrapped field?

It is a required field and I want to be sure they don't cheat by entering "." or something equally useless.  Users can be devious in sidestepping required data fields.  I wanted to do something like checking for a minimum length with the first character alphabetic, etc.  Not foolproof but better than just telling SD that it is a required field.

[precisonline]

Yeah, but that can also be done via file time validation in the PASA, right?

[nmorgan]

Yeah, but that can also be done via file time validation in the PASA, right?

Sure, but there are five or six of these fields, scattered through all four screens and I did not want the user to proceed until they provided valid data for each one.

We are talking about fields labeled "Describe the accident in detail", "How could the employee have prevented this accident?", etc.  You know how people will do anything to avoid a question that isn't Y or N or multiple choice.  You are asking them to think!  Many seem to find that painful.

[precisonline]

Yeah, I understand.  How about creating a process that verifies that a particular field is a "valid" comment, like maybe this:

LOCAL L.COMMENT
*
L.COMMENT = <@PARAM>
*
@VALUE = 1 ;* Assume everything is okay
IF LEN(L.COMMENT) < somevalue THEN
  @VALUE= 0 ;* Too short
END ELSE
  IF NOT(ALPHA(L.COMMENT[1,1])) THEN
    @VALUE = 0 ;* Not starting with alpha
  END ELSE
    ...
  END
END

Then - assuming you called this VALIDATE.COMMENT - from the PASA you could call this like this:

IF P('VALIDATE.COMMENT,' : POS(commentFieldName)) = 0 THEN
  ...do some error
END

What do you think?