EDITABLE = NO for a Field in Form still its editable

lavanyaballurgi

Its kind of strange but one of the field "VAT product posting group" in GL is not becoming uneditable. I specified EDITABLE = NO in the property of FORM. Can someone tell me where i am going wrong? (Note : I do not want to remove table relation & I want the lookup to still work)

mohana_cse06

Can you please tell us the form ID?

vaprog

Is the field editable by entering data into the control or is it changeable through lookup only?
In the latter case, do you have a default lookup (TableRelation property set only) or a programmed lookup (trigger code in Table or Form?)
With trigger code in the Table, I do not know how to correct other than adding trigger code on the form also.
With trigger code on the Form, you must modify the Text parameter, not the field directly and return TRUE if the returned value should be used; by no means you should modify the record in the trigger code on the form (On the Table you do not have another option other than setting the value of the field, and that's why it does not work).

A different approach safeguards by utilizing the OnModifyRecord trigger on the form. Make sure that you return false if the form is not editable. However, OnLookup code and OnValidate code, run on the field may already have altered this or other records at that point.

lavanyaballurgi

@ Mohana -Its a customised FORM similar to GL ACCOUNT CARD FORM
@ VAPROG - The field is editable both by entering manually & by selecting from lookup. There is a table relation with that field.

I am fine with OnLookup code and OnValidate code, run on the field may already have altered this or other records at that point. So you suggest I should code on "OnModify" trigger?

vaprog

lavanyaballurgi wrote:

So you suggest I should code on "OnModify" trigger?

No.
Your description of the problem was not detailed enough to really judge. The most probable case, in my judgement, was an incorrectly implemented lookup trigger on the form or a lookup trigger implemented on the table field. But in both these cases, the control is disabled on the form and you cannot edit it's contents directly (the find dialog comes up if you try).

The behavior you describe so far is unknown to me. To pinpoint it, I would create a new form in a testing environment, place the primary key and the "VAT product posting group" field on that form, set the form's editable property to no and test. Does it behave the same? Yes -> The problem is in the table or in your particular build of the client; No -> The problem is somewhere in your form. Check all code and all properties of the form and the misbehaving control.

By the way, how does the field look like? white background (normal, editable field) or grey background (non-editable field)? This question is about appearance only, not about behavior.

Peter76

One thought would also be that there might be code in the form that makes the field dynamically editable. For instance, if a security product like Lanham's Security or Easy Security from Per are installed, they change the fields on the form to editable based on the setups. It could also be custom code in the form that does that - look in the OnAfterGetRecord or OnAfterGetCurrRecord.