Hi all.

In AREV.COMMON there is a variable UNKEYS commented as:

List of keys to disable in this window.

Somehow I can guess, that the list should be @FM delimited.

What I can not guess is, how I should express the value of eg. SAVE key.

I try with "F9" - no good!

I try with SAVE.KEY from file INCLUDE,EDIT.KEYS - no good!

Is there anyone who knows?

Is it OK to set the value of UNKEYS in POST RECORD ?

By the way, is there a better way to protect records from change, after eg. invoice is registered by setting a field in it's record to 1.

Thanks Tony.

REVMEDIA FKB docs it as follows - although normally we'd use the technique in the following article…. (Just think if you'd bought REVMEDIA in 1989 you would have known this for nearly a decade now )

A field mark delimited list of keys which are to be disabled in the window.

Primarily used to link to the "Key Disable" option in Paint. This variable

is used by the system to modify WC_WExit_Keys% and WC_Except_Keys% (q.v.) by

swapping out the appropriate scan codes for the literal "!!" in these

variables. Thus once these variables have been changed they are no longer

affected by the contents of WC_UnKeys%.

As this swapping seems to be done AFTER the Pre_Init process it is possible

to amend WC_UnKeys% at the Pre_Init process by directly modifying @RECORD

which contains the current template record. This has the effect of changing

the disabled keys in the window. Note that this means that WC_UnKeys% can

only be effectively modified at the Pre Init stage - after this it is not

referenced again.

Note further that the same effect could be achieved anywhere in the window

by swapping the appropriate scan codes for the literal "!!" in

WC_WExit_Keys% and WC_Except_Keys% (q.v.). In either case, rather than

looking for the scan code itself one should use the EDIT.KEYS include record

look to ensure that if the user has remapped the keyboard that the scan code

will still be found.

There follows an example piece of code to illustrate the use of WC_UnKeys%

in a pre init process.

  Subroutine Kill_Refresh

    $Insert Include, Edit.Keys

    Equ Dlm$    To Char(247)

• Get Unkeys from @Record - from pos 43 delimited by char(247)s

    Un=Field(@Record, Dlm$, 43)

    Un=Refresh.Key

    @Record=Fieldstore(@Record,Dlm$,43,-1,Un)

  Return

Normally this should be sufficient, however under some circumstances (such

as with some collector windows and some releases of the software) this might

not be enough as Curt Putnam points out "the window processor sets flags

within the body of the template record to indicate whether there are any

further options to process". This helps speed up the loading process. These

flags are referred to in the TEMPLATE record in UTILITY.DOC as OPTIONS1 and

OPTIONS2 and are found in positions 20 and 35 respectively (delimited by

char(247)s).

Normally these flags are ALWAYS set as the system sets recalculate options

and WC_Atr_Ovr% automatically upon save and this is enough to trigger them.

If however you find that the above code does not work on the release of AREV

you are working with, try amending it by inserting the following two lines

after the @Record=Fieldstore line.

• Set Options1

 @Record=Fieldstore(@Record,Dlm$,20,-1,1)

• Set Options2

 @Record=Fieldstore(@Record,Dlm$,35,-1,1)

(Volume 3, Issue 10, Pages 11,12)

amcauley@sprezzatura.com

Sprezzatura Ltd

World Leaders in all things RevSoft

And how we suggested in 1989…

A user in Cardiff had a problem recently with trying to find an easy way of

preventing records from being amended when certain trigger fields had been

filled in. That is, they wished to allow time-sheets to be entered and

amended UNTIL an invoice had been produced. After the invoice was produced

(and the invoice number was stored in the time-sheet record) the user had to

be able to call up the time-sheet on screen and scroll through all values

but not amend anything. The question was - "What is the most efficient way

of achieving this ?"

The initial solution of setting all of the fields to protected worked but

was cumbersome. A more elegant solution was achieved by the realisation

that when a record is locked on the network, no editing is possible. Once

this was realised, duplicating this functionality provided the better

solution. The answer was to use a replace read process coded as follows

  $INSERT WINDOW_COMMON%

  READ @RECORD FROM WC_SRC_FILE%, @ID THEN

     IF @RECORD THEN

• Or whatever condition you wish to assign

        WC_WLOCKED%=0

        UNLOCK WC_SRC_FILE%, @ID

     END

  END ELSE

     @RECORD="

  END

The WC_WLocked%=0 instructs the window processor that the record could not

be locked and is therefore NOT available for editing. However because the

window processor thinks that the record is locked it will not attempt to

unlock it after the record has been exited. The record must therefore be

explicitly unlocked by the process.

(Volume 1, Issue 7, Page 3)

amcauley@sprezzatura.com

Sprezzatura Ltd

World Leaders in all things RevSoft

Nice solution. I think there is a typo, though. Shouldn't "However because the window processor thinks that the record is locked it will not attempt to unlock it after the record has been exited. " read "However because the window processor thinks that the record is not locked it will not attempt to unlock it after the record has been exited. " ?

Yup you are of course right… probably there in the original OR the person who did the transcribing made a mistake! Thanks!

amcauley@sprezzatura.com

Sprezzatura Ltd

World Leaders in all things RevSoft

This is (I hope) exactly what I am looking for.

The idea of fideling with UNKEYS (which came to me from my AREV supplier) was a good shot, only not good enough. Even if it would be possible to kill the SAVE key depending the content of read record, it still gives wrong impression to the user, that he can edit the record until he tries to save the changes.

The locking usage gives an "early warning", that is often very apreciated.

Thanks Tony.

View this thread on the forum...