In order for this site to work correctly, and for us to improve the site, we need to store a small file (called a cookie) on your computer.
By continuing to use this website, you agree to our cookies and privacy policy.
Home page Home page Home page Home page
Pixel Header R1 C1 Pixel
Pixel Header R2 C1 Pixel
Pixel Header R3 C1 Pixel

Reader's Clinic - Related Windows

Several readers have asked "When I call a related window from my current window to add related records, is it possible to have my current window reflect these changes when it returns?"

In the classic customer/invoice example, the invoice window might be a related window from the customer screen. The user might be able to softkey to the invoice window, add another invoice and then return to the customer window. Under these circumstances, @RECORD contains the linking IDs and being in memory is not updated.

Note that the system routine responsible for updating related indexes (RELATER) checks to see if the lock set on the file to be updated is that of the current workstation (i.e.STATUS() is set to 1). If so the lock is ignored and the update takes place regardless. This is because when a record is written to disk, SI.MFS reads the old record in and ensures that any protected fields (as "related to" fields would be) are the same as the disk copy. If not they are changed to reflect the disk copy.

Thus on the post window code and command option for a related window, a call to a commuter program that simply reread the new values and inserted them into @RECORD could be used. If the values were displayed on screen, WC_DISPLAY.ACTION% and WC_RESET% would also need to be set to redisplay the new values. E.g.

0002   * We already have lock so just ignore it and continue with the read
0004      * Replace appropriate field numbers here
0005      @RECORD<22> = R<22>
0006      * If needed
0007      WC_DISPLAY.ACTION% = 7
0008      WC_RESET% = 5
0009   END
0010  RETURN

(Volume 2, Issue 9, Page 3)
Pixel Footer R1 C1 Pixel