I use to be able to save the current record by assigning from

softkeys (SF9) to call the subroutine below. It was so the

data entry person could save the record with out having to

save it with F9 then Alt-O to bring it back.

But now that I've upgraded from Arev v1.16 to v3.12

What happens is the data gets saved the cursor move to the

key prompt (with current id still on prompt) and if you push

enter or arrow down or up. Then all data disappears but in

the status line it show that it still has the same key but all

data is gone. If I refresh the window (SF8) and then Alt-O

to recall last key then all data returns. What the heck

happen to this procedure? Is there a work around ?

(Mike if you read this then please put some people on the

source code for 3.12 and get these bugs fixed)

SUBROUTINE SAVE.REC

$INSERT SYSINCLUDE,AREV.COMMON

SAVE.REC=1

RESET=5

RETURN

END

-OR-

SUBROUTINE SAVE_REC

$INSERT SYSINCLUDE,WINDOW_COMMON%

WC_SAVE_REC%=1

WC_RESET%=5

RETURN

END

Frustrated Bob

Why not just:

WRITE @RECORD ON WC_SRC_FILE%, @ID
WC_OREC=@RECORD 

The record should be locked so you don't have to worry about it.

Version 1.x seemed to 'protect' @RECORD, @ID, etc. whereas version 2.x onwards requires the programmer to protect these especially when calling various system subroutines or using catalyst calls. Something like this could be going on here.

Yeah true Warren just now I must do a check to see it the

current workstation has the lock but this may not be good.

If the user has the record up in a lower level window (ie 2)

and is currently at level 6 with the same record and I

try to write the record then there is potential for the lower

level data to over write the high level data.

This is why in the past (before the upgrade) I used the

systems methods for this process.

Much thanks for the quick response & if you or anyone else

has any thoughts. I'm a listening

Bob

]]If the user has the record up in a lower level window (ie 2)and is currently at level 6 with the same record and I try to write the record then there is potential for the lower level data to over write the high level data.«

Ours not to ask why this situation would exist in the first place, but why not put @ID and/or the level into one of the @USER registers or other common space at post read time as a LIFO stack and check it prior to your write. You can pop the stack when you exit the window or record.

What am I thinking? Just do this:

If WC_WLOCKED% Then
   Write @RECORD to WC_SRCFILE%,@ID
   WC_OREC%=@RECORD
End Else
   Call MSG('W586','','',@ID)
End

IF WC_WLOCKED% is 1 then it means the current window has it locked. If it is 0 then it means it is locked previously by yourself or some other workstation, regardless if a different level or concurrent instance of ARev under Windows.

Try using the PreserveKey and PreservePrompts WC variables.

You can set this from the window or programmatically before the save.

This should do what you want.

The Sprezzatura Group

World Leaders in all things RevSoft

It wouldn't be a bad idea to loop through and check WC_REQ_FIELDS% prior to the write either.

Boy, am I out of it. WC_SRC_FILE% should be WC_DATAFILE%.

Shame on me for not catching it earlier.

View this thread on the forum...