I'm lost in a maze of twisty subroutines...

[nmorgan]

I'm beating my head against the wall over something that should not be that hard.  I'm writing a side system to go along with Activant Prelude's work orders.  It will track work orders for rebuilt product that fail initial quality testing.  I'm writing a record in a separate file that has the same ID structure as the work order header.  I need to validate the work order number the user enters against the existing work order and extract some data as defaults for my record.  The catch is that a work order number could exist in one of three places:  it could be a quote and be in WO.QUOTE; it could be open and be in WO; or it could be closed and be in WO.HISTORY.  I use Prelude's KEY.C!W2 process to build the item-ID from @WORK<2> on the screen, then call a Basic program to do the validation by first checking WO.STATUS to see which file the work order is in, then reading the record from the appropriate file.  Along the way, I warn the user with a dialog box if the work order is a quote or history item, but allow them to continue if they wish. I pass the default values by loading them in @WORK<nn> variables and naming the work variables in the DEFAULT slot on the record's field definitions. Some of the default data I load in my screen is the list of mechanics who worked on the order, taken from the burdened hours of WO.LINE records for burden item LABOR.

My problem is that even though my screen header says Defaults Up Front? Y, the default values don't appear until you step through the fields.  AND when you get to the MV field with the mechanics initials, it wants to endlessly repeat the last entry.  You can \ and move on, but this confuses the non-techie wrench-benders who are trying to enter this data.

So I tried adding code to the validation/defaults program to directly stuff the defaults in @RECORD on @ACTION = 1, then set @RTN.FLAG to S5 to position the cursor beyond the mechanics initials (which they should not normally have to touch), and set @REFRESH to -2.  Now all the data appears immediately on the screen with the cursor exactly where I want it, BUT it wipes out the contents of the work order number on the screen (@WORK<2>).  However, a peek with /COMMON reveals that @WORK<2> does indeed contain the correct value, as does @KEY.  I have tried other values of @REFRESH, but that only seems to make things worse.

Is my whole concept here totally screwy?  Am I overlooking a much simpler way to do this?

[precisonline]

1) Sounds like your screen needs a read step.  When there's a multi-part key (as in the case of Prelude's WO file [where the CONO is concatenated to the front of the work order #]) you need to be sure Control/Dep/Read is a "R" on the work order number prompt.  Alternatively, if you are loading @RECORD in the PA on the work order number field, use RIA in the Control/Dep/Read so that SB+ can differentiate between the key and record parts of the screen; that's what triggers the Defaults Up Front.

2) As to the "\" on the mv'd mechanics initials, wrap an IF(..) function around the variable that holds the initials in the default expression.  So if the initials are coming from @USER.ID, maybe a default like this would work?

IF(@CNT = 1,@USER.ID,'')

This way, the default happens only on the first mv.  Make sense?

[nmorgan]

I have the R on the Controllling/Dependent/Read on the work order number (WK.WO.NUM aka @WORK<2>), which is the first field on the screen.  The concatenation of the key happens on the PA slot for that field, and the subroutine is called from the validation process o9f the dictionary item for WK.WO.NUM.  I tried the RIA and it didn't seem to make any difference.

The mechanics initials are from the existing work order and are different from the current USER.ID (which would be the test technician, a different field).  Here is the snip if code that loads the initials:
     WORK<54> = ""
     NUMDTL = DCOUNT(WOHD<40>,VM)
     FOR DX = 1 TO NUMDTL
        GOSUB FindMechanics
     NEXT DX

FindMechanics:
     WOLN.ID = WOHD<40,DX>
     BEGIN CASE
        CASE FILE.FLAG = "Q"
           READ WOLN FROM F.WO.QUOTE.LINE,WOLN.ID ELSE RETURN
        CASE FILE.FLAG = "W"
           READ WOLN FROM F.WO.LINE,WOLN.ID ELSE RETURN
        CASE FILE.FLAG = "H"
           READ WOLN FROM F.WO.HISTORY.LINE,WOLN.ID ELSE RETURN
     END CASE
     IF WOLN<27> # "LABOR" THEN RETURN
     TEMP = WOLN<114>
     CONVERT SVM TO VM IN TEMP
     NUMMEC = DCOUNT(TEMP<1>,VM)
     FOR MX = 1 TO NUMMEC
        MECH = TEMP<1,MX>
        LOCATE MECH IN WORK<54> BY "AL" SETTING SPOT ELSE
           WORK = INSERT(WORK,54,SPOT;MECH)
        END
     NEXT MX
     RETURN

As for the @CNT thing, it would almost have to be something like IF @WORK<54,@CNT> = @WORK<54,@CNT-1> THEN etc...

[precisonline]

A couple of things.  First, the validation will happen before the PA and both happen before the read step, so if you read the record in the validation or in the PA and the Control/Dep/Read is just "R", @RECORD will be read in the read step and will possibly overlay the @RECORD that might have been loaded in the Validation.  Also note that if you set @RECORD outside of the read step, you should also set @ACTION to 1 (if new) or 2 (if existing).

If you want to use the read step to load the record, simply set MAINFILE to the name of the file where the record can be found (which your subroutine is determining anyway, right?) and then open MAINFILE to F.FILE in your subroutine.  Really, the read step is simply this line of code:

READ RECORD FROM F.FILE,KEY THEN
  ACTION = 2
END ELSE
  RECORD = ''
  ACTION = 1
END

...so you should be able to use the validation or PA to change F.FILE and have it work, and this would also make sure @ACTION is set properly.  As to the @CNT thing, I agree with you but make sure @CNT is > 1 before comparing to the previous position.  If this is being called from a default it might make for a good paragraph rather than trying to string it all together into one big expression.

[nmorgan]

I finally got it to work right.  I had to split the Basic code into two parts, one to do the tricky validation, the other called at PA to do the read and load of defaults.

I was going nuts...a journey that gets a little shorter every day.