I found the users of our system modify values of fields by placing the cursor on the field and pressing F1 to invoke the Helproutines, selecting a new value and pressing ENTR, to update all fields.
If the function is started and the user tab from one field to the next these fields are never available as they are protected via a control-variable carrying (AD=P)
How can I prevent the Helroutine from been invoked on these protected fields.?
Is this a field-level help? if so, did you want to not remove the helproutine - that is, is the helproutine providing a decode that you want to retain, just not allow the modification? Is the helproutine decode shared with the maintenance routines?
Hi Douglas,
this is firld level helprouine. It was probable used the first time when data was entered. during the next function the user enters the detail screen with a MODify function, but I protect certain fields.
I would like to prevent any modification to the field in any way.
I was considering adding the field content to a #VAR and before storing doinig a comparison to determine whether it canged, and if so overwriting the change with the original data.
Looking for a better neater solution though
Deon
You could pass the control variable you are using to protect your field as a parameter to the help routine and use it to protect the input field on the help map.
There is always the OPF profile and session parameter. The default setting is ON which means that write-protected fieds can be overridden from a helproutine. If it is set to OFF, then the field that the helproutine is on will not be overwritten if the field is write-protected. This allows the user to still execute the helproutine and even select a value but the selected value is not returned to the write-protected field. And you don’t have any special coding in the helproutine.
We use the profile parameter, so it is in effect for everyone. Which is what I prefer. I think if a field is write-protected, then a helproutine should not change its value. But if your shop doesn’t want that, then you can modify it for this one application by using the SET GLOBALS command to change it to OFF and then change it back to ON before leaving the application. Preferrably a subprogram that you would call to change its setting. That way you call the subp at the start of the program to set it to OFF and at the end to set it back to ON. And then you could use this same subp in any other programs. And this would take care of your problem on any write-protected fields in the application that has a helproutine attached.
Below is what the documentation says. Pay close attention to the first note at the end:
OPF - Overwriting of Protected Fields by Helproutines
This Natural profile and session parameter specifies whether the content of a write-protected field (attribute AD=P) can be overwritten by a helproutine assigned to the field.
Within a Natural session, the profile parameter OPF can be overridden by the session parameter OPF.
Possible settings:
ON - A helproutine assigned to a field can overwrite the field’s content, even if the field is write-protected.
OFF - Helproutines cannot overwrite the contents of write-protected fields.
Default setting - ON
Dynamic specification - YES
Specification within session - YES
Applicable Statements: SET GLOBALS
Applicable Command: GLOBALS
Notes:
The OPF profile parameter only applies to the field for which a helproutine is invoked; it does not affect parameters explicitly passed to the helproutine. This means that the OPF profile parameter takes no effect if the field for which help is invoked is also explicitly specified as a parameter to be passed to the helproutine.
In addition, in reporting mode you can change the OPF setting using the statement SET GLOBALS.
In terms of programming ease, OPF is probably the way to go.
HOWEVER, what does this mean for the poor end-user who thinks they have effected a change and in reality have not done so.
I would suggest a variant on Jerome LeBlanc’s suggestion. Pass the Control Variable; test for the protect bit. If set, do not display the menu that permits a change. Instead, display something like:
#INCOME cannot be modified at this screen
Press ENTER to return to the Map
steve
The poor end-user will see that the value has not changed. :lol:
I guess other things would need to be considered. Like is the helproutine already used in a million places? If not, will it be?
We went with the OPF parameter because it kept things consistent. That way the end-user gets the same results on all protected fields with a helproutine. That way they don’t get confused about what they can change and what they can’t change. If it’s protected you can’t change it, but you can still execute the help if you like.
Hi Trent;
It sounds as if you started out with OPF off; which is fine.
However, in the original post YBK indicated their users are used to having OPF set to ON. While you said “The poor end-user will see that the value has not changed.”; that may not be true.
The user will see the change in the helproutine (too bad this is allowed), hit enter to get back to the Map, and may immediately hit enter again, since they KNOW that the change was made.
Different environments, requiring different actions.
steve
Hi All,
a good South African morning to you all. Thanx for the great feedback.
I really dont mind whether the helproutine is invoked or not, my main concern is with the data caontained in a protected field. In these caes where the field are protected I dont want the values changed, thats basically the bottomline. Somehow a user came up with the brilliant idea on how to go abt it. . . Now its becoming a problem.
Hi Steve,
Actually, we started off with OPF on, mainly because that is the default. We also had problems with users changing protected field values through helproutines. We presented two solutions to management: 1. OPF 2. Check a value and not display the helproutine or give a message or something ( Jerome LeBlanc’s and your solution). And management decided to go with the OPF profile parameter, again for consistency. We’re big on that here.
So YBK, sounds like you have a few options. As Steve stated, you’ll have to choose the right solution for your enviroment.
Trent Brazeal
Lane Furniture Industries
The advantage that I see to passing the control variable to the help routine is the user can still access the field help but it is clear that they cannot change the data. Since I am so fond of sample programs, here is a program with a helproutine you can try out.
** Program: NAPTCV
DEFINE DATA LOCAL
1 #ID (A8) INIT <'ABC12345'>
1 #PROTECT (L)
1 #CV (C)
END-DEFINE
*
SET KEY ALL
SET KEY PF1 = HELP
*
RPT.
REPEAT
IF #PROTECT
MOVE (AD=IP) TO #CV
ELSE
MOVE (AD=I) TO #CV
END-IF
*
INPUT (AD=MILT'_')
// 6T 'Personnel ID:' #ID (CV=#CV HE='NAHRCV',#CV )
/ 8T 'Protect ID:' #PROTECT
// 6T 'Press <F8> to exit.'
IF *PF-KEY NE 'ENTR'
ESCAPE BOTTOM (RPT.)
END-IF
END-REPEAT
*
END ** Helproutine: NAHRCV
DEFINE DATA PARAMETER
1 #CV (C)
1 #ID (A8)
END-DEFINE
*
DEFINE WINDOW HELP
TITLE 'Help Routine Example'
*
INPUT WINDOW='HELP' (AD=MILT'_')
'This is just a simple help routine'
/ 'that puts up a window to help you'
/ 'learn how to use windows and help'
/ 'routines.'
// 'The value of #ID is:' #ID (CV=#CV)
*
END For simplicity here I have converted the INPUT USING MAP to a direct INPUT, but this works just as well with maps. You can set OPF=OFF also, if you are the kind of person who wears a belt and suspenders.
Hi All,
Our site is using both IMS and CICS, and boy do I wish Natural ran on CICS…
I have taken the liberty to try some tests with OPF. The reason been that if the OPF is set, it effects a system wide consistency at once, without me having to change any program.
Changing the programs, whether sending the CV with, is my last resort. I am a bit of a lazy programmer, wanting the max result with the least code (if any).
The helroutine in question is used in eleven places in the system, already. It was by accident it came to light of the possibility to use it to change field content. A student changed showed us.
In any event, under IMS it has no effect. I changed the parameter and tested. Kept the results, then changed the value again. Still no change to the result. The only thing which I have not done was to compile the program under changed global parameter. I cant see this making any difference though.