I'm modifying a window for some new processes and what I want to do is be able to save a record, then have that record stay in the screen instead of emptying out and getting ready for a new record. The reason is that I want the user to be able to go to a different window (with a softkey) and create a related record, and for that to work the first record has to be saved in the database already.

That seems simple enough, and I have searched the site looking for solutions but so far nothing worked.

I tried saving the record to a local variable (temp_var=@RECORD) in the pre-save process, then putting it back (@RECORD=temp_var) in post save process. no luck, I tried setting PRESERVE.KEYS$ and PRESERVE.FIELDS$ to 1 in presave, no luck. I looked at the Windows variables documentation and it seems that that's not how the preserve variables work, although a post I found here implied it was.

Any help is welcome, it seems like such a simple thing but I'm running out of ideas.

We're using Arev 3.12 with the NPP/W2k Service, server is W2k SP4, workstations are all W2K with an XP machine here and there.

Thanks in advance;

David Craig

ABC-CLIO

Assuming you have a 'bound' window - one that uses the dictionary, I would have the Softkey instead of using a "W" (Window) code, use a "S" (Subroutine) code.

The suboroutine would write @RECORD to your table, then if successful continue with the second window, launching it with the Catalyst subroutine. If the write is not successful, some error handling would occur, and you would I guess not want the user to go onto the second window.

Since the second window will also likely use a dictionary, it will overwrite @RECORD, @ID, etc with it's own data, so you can use PUSH.SESSION(cursor,sentence,record,id,dict,mv) before the Catalyst subroutine and POP.Session(cursor,sentence,record,id,dict,mv) after the second window is done, to save your first windows data.

PUSH.SESSION and POP.SESSION are double super-secret Subroutines, I think the book named "System Subroutines" in is the downloads section (which documents other useful System Subroutine too).

Thanks Ralph, I'll give that a try and post the result.

David Craig.

David,

Depending on just what you want to do you might try a couple of things.

1. There is an option under default value that sets the default for the field to whatever was the last value placed in it.

2. How about reminding your client that they can do an ALT-C to re-populate the window with the values of the last record read or maybe even figure out a way to do this as a code/command on a post process….. I have never tried it with a code/command.

3. Last but not least experiment with the advanceded -] customize -] preserve prompts values. This also sounds like it might work.

Hope this helps.

3.

You guys are trying too hard!

When you press the SoftKey:

assuming name of the related window is NEWDATA

$INSERT SYSINCLUDE, WINDOW_COMMON%

*you don't need to save off ANY variables,

*including @ID, @DICT and @RECORD

IF WC_KEY_FULL% AND WC_WLOCKED% THEN

• must have a current key? must be ok to save

WRITE @RECORD TO WC_SRC_FILE%, @ID ELSE NULL

• here you might save a @RECUR or @USER to save off the current @ID

• so that you can default it when in the related window

CALL CATALYST("W","NEWDATA")

• you are back in the original window after closing NEWDATA

• remember that is you have a Relational Index to this row it

• will be updated on disk, but not in memory (@RECORD)

END

Dave

Thanks everybody, I'm back working on this again and now I have several approaches to try.

David Craig.

I ended up solving this by using a softkey to call a program. The program uses the window common variables and for a new record it has to save the new child record (with the parent id) and then save the parent record to update the Xref index. When there are already child records it loads them into the window.

The windows common variables was a great tip, also push.select/pop.select are good tools to be aware of. I couldn't find documentation anywhere on them (just push/pop.session in the KB) and I'm sure I'll find them useful in the future even though I didn't need them for this.

Thanks again to everybody who replied,

David Craig.

There was one bug caused by this solution we discovered yesterday. The parent record contains several text fields that wrap in the window, when you save @RECORD, @ID the fields were getting textmarks inserted into them where the line wrapped in the window.

This was solved by cleaning the fields right before the save in the program called. I'm posting this in case someone else follows this thread and runs into the same problem.

David Craig.

ABC-CLIO

View this thread on the forum...