April 20, 201213 yr Im running a db on my iPad to tracking students projects. Once a project is "closed", I must protect the evaluation fields. Used an old script called "Lock evaluation_field". If (table_status="closed") Show Custm Dialog ("Sorry, cannot change the evaluation") Else Go to Field (evaluation_field) End If Well, the script lets me to alter the evaluation anyway. It doesnt lock the field. I think this script worked for me in the past for FM 10 Pro, as I pointed it out. Please help me to refine this. Many thanks once more :)
April 20, 201213 yr Well, the script lets me to alter the evaluation anyway. It doesnt lock the field. I think this script worked for me in the past for FM 10 Pro, as I pointed it out. If this is a script trigger on field entry, you need to direct them to another field or issue confirm record to clear your entry into a field.
April 20, 201213 yr Author Not clear to me. The script works as if project is "closed", the message will appear, but after I change the value. Could you be more detailed please? Thanks
April 20, 201213 yr Could you be more detailed please? I'm assuming that this.... If (table_status="closed") Show Custm Dialog ("Sorry, cannot change the evaluation") Else Go to Field (evaluation_field) End If is a script trigger that is fired when you enter the field your not wanting modified after locking. Your script is throwing a notification that its not able to be changed, but your not redirecting that users entry into that field. So when I click on the field, I've already entered it. Then your script fires and notifies me that I cannot change it, then exits. This leaves me inside the field you don't want edited. You need to add a redirection from that field, or confirm records. If this is not a script trigger, explain how your using the referenced script?
April 26, 201213 yr If it's a drop-down list and you are using onObjectModify, the script will fire after the value is already changed. Add a revert record step. Or if you use an onObjectEnter script trigger, adding commit record step will throw them back out of the field as well.
April 26, 201213 yr All of which does nothing to protect the field from being changed. Look at Access Privileges. Steven
April 26, 201213 yr An easy way is to apply two layouts, one for editing records and other to see only. It’s a fast method, so when the project is closed it jumps to other layout, so the fields are "protected". Other idea is to have different privileges sets (security side). Best way to protect like as told by Steven Blackwell.
April 26, 201213 yr The easiest approach to me seems to be the one that Russell Barlow suggested in his two posts. In his sample script, after the Custom Dialog step add a "Go to Field", with no target field specified, which is the same as clicking outside of any field: If (table_status="closed") Show Custm Dialog ("Sorry, cannot change the evaluation") Go to Field [ ] Else Go to Field (evaluation_field) End If As shown above, even the Else part is not necessary; since the user has entered the field, doing nothing will leave him inside it. Faster to set up than Access Privileges, and easier to maintain than two layouts (unless you need to protect a number of fields).
April 27, 201213 yr In his sample script, after the Custom Dialog step add a "Go to Field", with no target field specified, which is the same as clicking outside of any field: If (table_status="closed") Show Custm Dialog ("Sorry, cannot change the evaluation") Go to Field [ ] Else Go to Field (evaluation_field) End If No, no no no. This was bad practice back in FMP 6 days, please do not start recommending it now. Use Commit Record/Request.
Create an account or sign in to comment