Ok, I know I am missing something, so any help is appreciated.

Situation -

Data entry window (Inventory Window), user enters the Item ID -

   If the Item ID is in the "active" table, then display data, else

   check the "History" table and if found in the History table 

   call up the "Inventory History" window passing the Item ID

   information the user entered and display that data, then when

   the user escapes or saves (cannot change data in history), 

   system reverts back to the "Inventory" Window.

There are probably several ways to do this. One would be to put something in the post-read process that does the logic you describe. It does a PERFORM 'WINDOW window_name ':@ID if necessary to display the history screen. When the user exits the history screen, you're back at the original screen.

Thanks for the response, however the post-read process did not work.

Here is the code I finally had to do to pass the data to the history window, call up the history window with the KEY passed and to be filled in, then when the user escapes or saves the history window, it goes back to the active inventory window without locking a record in the active inventory window (as users will do ANYTHING they can to screw it up)…

EXPENDABLE SUBROUTINE IHW

$INSERT SYSINCLUDE,WINDOW_COMMON%

DECLARE SUBROUTINE MSG

DICT=@DICT

RECORD=@RECORD

ID=@ANS

OID=ID

IF ID THEN

OPEN 'INVENTORY.HISTORY' TO IHF ELSE MSG('FILERROR','','','INVENTORY.HISTORY') ; STOP

OPEN 'INVENTORY' TO AIF ELSE MSG('FILERROR','','','INVENTORY') ; STOP

UNLOCK AIF,OID

READ IHREC FROM IHF,ID THEN

  @RECORD=IHREC

  @DATA=ID

  CALL CATALYST('W:','INVENTORY.HISTORY')

  @DICT=DICT

  @ID='

  @RECORD='

  @ANS='

  WC_WI_NEXT%=1

  WC_RESET%=4

  WC_DISPLAY_ACTION%=5

END

END

@DICT=DICT

I think you are having to do a lot of extra work because post-read is not the best place to do this.

I would do this post-prompt, something like:

ID=WC_IS%

ACTIVE=XLATE("ACTIVE.INVENTORY",ID,0,"X")

IF LEN(ACTIVE) THEN

• active item-just return

END ELSE

  HISTORICAL=XLATE("INVENTORY.HISTORY",ID,0,"X")

  IF LEN(HISTORICAL) THEN

     CATALYST("W", "INVENTORY.HISTORY": ID); *<- better than using @DATA; will call window with ID active

  END ELSE

• bad ID processing: MSG or whatever

     WC_VALID%=0

  END

END

No worries about locking, no messing with @RECORD, etc.

David

Your problem is that @DICT may be pointing to the wrong dict handle if there are any dict calls in the new window.

* Save off old values in @RECORD,@ID,@DICT

OLDREC-@RECORD

OLDICT=@DICT

OLDID =@ID

* then you can swap things around to suit you

IF ID THEN

OPEN 'INVENTORY.HISTORY' TO IHF ELSE MSG('FILERROR',,,'INVENTORY.HISTORY') ; STOP

OPEN 'INVENTORY' TO AIF ELSE MSG('FILERROR',,,'INVENTORY') ; STOP

UNLOCK AIF,OID

READ IHREC FROM IHF,ID THEN

• OPEN "DICT.INVENTORY.HISTORY" TO @DICT THEN

  @RECORD=IHREC

  @ID=ID

  @DATA=ID

• since the next window expects these variables to be set properly

  PERFORM "WINDOW INVENTORY.HISTORY ":@ID

• on return you will have the values of @ID and @RECORD with

• any changes made there

• with a little clever programming you can make this screen

• a one-shot such that F9 or ESC will both close the window

• and exit

  @USER1=LINK'

• then in the form Set WC_RESET=5 ;* this will blow off the

• form. Do this after the write and if the key is pressed

* CALL CATALYST('W:','INVENTORY.HISTORY')

  @DICT=DICT

  @ID='

  @RECORD='

  @ANS='

I do this fairly regularly and it has been working for years.

Don Miller

C3 Inc.

Going back to the original item - another way to tackle this, which we've been using since quite early Arev days.

We have pairs of live files and archive files.

The live files have an MFS which does various things, including :-

1) On read, if file error 100 (record not found), it tries to read the record from the archive file (naming convention OLD_filename).

2) On delete, the record is deleted from the live file and copy written to the archive but with a deleted date entered in a data field. This is the flag as to whether the record is live or archive.

3) On write it enters creation or amendment date in data field.

4) On open it looks at %FIELDS% for the created, amended and deleted datestamp fields and appends data positions of those found to the file handle.

5) The archive dictionary has a different MFS which reads the dict record from the live file's dict if not found in the archive dict. Local definitions required for any indexing - but otherwise it's a bit like RList's "USING" but easier and automatic.

There's a lot more to it - but I hope this gives enough to consider an alternative approach to the current and/or other situations.

View this thread on the forum...