Access changed to "readOnly"

[Former Community Member]

Sometimes when I alter scripts in certain events in buttons and radio buttons (I've noticed it with the calculate event, but it may occur with others) the button becomes read only.  It took me the longest time to figure out how to go into the XFA Source tab and delete the access="readOnly" thing in the source code for the object.  1. Has anyone else experienced this?  2. Has anyone figured out how to stop LiveCycle from doing this?  It's probably trying to be helpful, but it's only a pain.

[Former Community Member]

Update-now on any of my buttons with scripts in the "calculate" event the access gets changed when I change a script in the "click" event as well.  This is really annoying!

[Former Community Member]

Another update-it does this when I modify scripts in the "calculate" event of subforms.  Are there some items that just don't automatically support scripts in the "calculate" events, or is it always automatic that objects with scripts in the "calculate" event are made readOnly?

[Niall_O_Donovan]

Hi,

I have never scripted a button in its calculate event. I know from other fields that when you setup a calculate event, LC will automatically turn the field to "calculated - read only"; however it is easy to change this back in the Object / Value tab.

I think it would be best/safer to try and not use the calculate event for buttons.

Also if the form is lengthy, then have all of the fields using the calculate event can hit your performance. Becuase the calculate events are fired as the user works through each field. Try exit event or change event, which will only fire for that field.

Good luck,

N.

[Former Community Member]

Unfortunately, the objects I'm scripting don't have a Value tab under the Object tab.  I can't figure out any way to do this stuff outside the calculate event.  For example, I'm scripting buttons to change in height based on the height of a subform, so I put something like

this.minH = (xfa.layout.h(Subform, "in")) + "in";

in the calculate event.  The button's size needs to adjust every time the subform's height changes, so the calculate event seems to be the only place to put it.  The other thing I'm doing is saying "If these three radio button groups all say 'no' then remove this subform", so in the subform's calculate event I put

if ((RGB_1.rawValue + RGB_2.rawValue + RBG_3.rawValue) === "222") {
_Subform.removeInstance(0);
xfa.form.recalculate(1);
Yes_No_Base.rawValue = "2";
}

(Unfortunately, currently the Yes_No_Base.rawValue = "2"; line doesn't work right now, and I can't figure out why).

My form is long, and I am worried about performance, but according to the LiveCycle documentation it only fires when the values the script is dependent on change, so my first script only fires when the value of RGB 1, 2, or 3 changes.  That shouldn't affect performance except when I'm changing those values, right?

[Niall_O_Donovan · Accepted solution]

Hi,

You could use the layout: ready event of the button  for your script instead of the calculate event.

Try moving the Yes_No_Base.rawValue = "2"; line before the xfa.form.recalculate(1);

When previewing the form in Acrobat, press control+J to open the javascript console, which will show up errors if they exist.

The calculate event was explained to me as firing each time the form changed. Where we had an object that pushed a value out to another field, we moved the script from the calculate event to events like the exit event. If an object is dependant on other fields to get its value, then it makes sense to keep the calculate event.

Check out Adobe's "LiveCycle Designer ES Scripting Basics", for good expaination of events.

Good luck,

Niall

[Former Community Member]

This is working as designed. Let me give you the background. If you write script on the calculate event of any field/subform, then Designer will change the access to ReadOnly in the xdp source for you. The reason being that if you are scripting on the calculate event then the user should not be typing in that field. If we did not do that then acrobat/reader woudl put up a message asking if you really want to override this field (because it is a calculated field) everytime the user accesses it. By making it readOnly the user cannot access it and the message will not appear. I have entered an enhancement to warn the Form Designer when this happens so that they are aware that the product has changed the access on you. Bottom line is that if you want to allow the user to inetract with the field you should not be using the Calculate event. I believe that the automatic access change was added in version 8 so version 7 will not act this way.

Hope that helps clarify the confusion.

Paul

[Former Community Member]

Thanks, Niall and Paul, for your help.  Everything is working except the " Yes_No_Base.rawValue = "2"; " thing.  I tried putting it before the "xfa.form.recalculate(1);" line, but it didn't help.  Any other ideas?  Now I understand about the calculate event and have removed all of my scripts from it.  As far asI can tell everything behaves pretty much the same in the layout::ready event, and I don't get the access changed every time I mess with something

[Former Community Member]

YesNoBase sounds liek a RadioButton Group .....the on/off values are usually 1 and 0. As a test, you can put a button on the form (next to the YesNoBase). Set the field manually the way you want it and then on the click of the button do an app.alert(YesNoBase.rawValue). This will show you what the value that the object is expecting when you set it.

Hope that helps

Paul

[Former Community Member]

I figured it out-I just put the script in the radio button group's layout::ready event rather than the subform's layout::ready event.  For some reason my radio button groups have values 1 and 2 (1 is yes, 2 is no).  I'm not sure whether I set it that way or if it's a quirk in the way my program is set up, but it works, so I don't really care.