[[https://www.revelation.com/|Sign up on the Revelation Software website to have access to the most current content, and to be able to ask questions and get answers from the Revelation community]]
==== UNKEYS (AREV Specific) ====
=== At 10 NOV 1998 09:13:46AM Tony Smisovsky wrote: ===
{{tag>"AREV Specific"}}
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.
----
=== At 10 NOV 1998 12:47PM amcauley@sprezzatura.com onmouseover=window.status=why not click here to send me email?;return(true)", [url=http://www.sprezzatura.com" onMouseOver=window.status=Why not click here to visit our web site?';return(true)]Sprezzatura Ltd[/url] wrote: ===
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
[url=http://www.sprezzatura.com" ]Sprezzatura Ltd[/url]
[i]World Leaders in all things RevSoft[/i]
[img]http://www.sprezzatura.com/zz.gif[/img]
----
=== At 10 NOV 1998 12:54PM amcauley@sprezzatura.com onmouseover=window.status=why not click here to send me email?;return(true)", [url=http://www.sprezzatura.com" onMouseOver=window.status=Why not click here to visit our web site?';return(true)]Sprezzatura Ltd[/url] wrote: ===
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
[url=http://www.sprezzatura.com" ]Sprezzatura Ltd[/url]
[i]World Leaders in all things RevSoft[/i]
[img]http://www.sprezzatura.com/zz.gif[/img]
----
=== At 10 NOV 1998 01:20PM Victor Engel wrote: ===
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 [b]not [/b]locked it will not attempt to unlock it after the record has been exited. " ?
----
=== At 10 NOV 1998 01:33PM amcauley@sprezzatura.com onmouseover=window.status=why not click here to send me email?;return(true)", [url=http://www.sprezzatura.com" onMouseOver=window.status=Why not click here to visit our web site?';return(true)]Sprezzatura Ltd[/url] wrote: ===
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
[url=http://www.sprezzatura.com" ]Sprezzatura Ltd[/url]
[i]World Leaders in all things RevSoft[/i]
[img]http://www.sprezzatura.com/zz.gif[/img]
----
=== At 10 NOV 1998 06:15PM Tony Smisovsky wrote: ===
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.
[[https://www.revelation.com/revweb/oecgi4p.php/O4W_HANDOFF?DESTN=O4W_RUN_FORM&INQID=NONWORKS_READ&SUMMARY=1&KEY=37CF19BCC71BC040852566B8004E2A44|View this thread on the forum...]]