Create a new account and associate it to a privilege set which does not allow editing of records, like the already existing [Read-Only Access].
Set your drop-down to be a pop-up menu and add a OnModify trigger to it. The triggered script looks like this:
Commit Records/Requests [ With dialog: Off ]
If [ YourSolution::gLockEdit = "YES" ]
Re-Login [ Account Name: "NoEdit" ; With dialog: Off ]
Re-Login [ With dialog: On ]
Also make sure that the field (in my example I called it gLockEdit) is defined as global.
I think there is a simpler way.
Create a script that does a "commit record" script step if the dropdown field has a value of "Yes".
Put this script as a script trigger on the "OnObjectEnter" event on every field you do not want to have edited.
What this does is, as soon as you enter the field the script will check if the "Do not edit" dropdown is set to "Yes".
If it is then the field will be committed, that means you exit the field and therefore can't edit it.
This will happen every time you try to enter this field so it's impossible to change the value in the field.
Put this script trigger on every field you want to make un-editable.
The script would be:
If [ Table::Dropdownfield = "Yes" ]
Commit Record / Request
Have you considered just making all the fields non-editable in the Inspector and using an "edit" popover? You can simply disable the popover if you want to lock the record.
Mike, is there an example file showing this method? and/or blog post?
You can simply disable the popover if you want to lock the record.
That would make it hard to go from editable no to editable yes...
It is not clear though what "my data" means for OP, i.e. it if concerns all records or only the current record.
I assumed "my data" means exactly that. (All my data).
Uh, why? Hide Object When pulldown = “No”. Really not that hard.
One of the starter solutions has a popover for editing. Don’t know which right now. But that’s the basic concept: All your fields are non-editable on the main Form view, and to edit, you click an “Edit” popover. This just says hide that popover button when the editing isn’t allowed.
have you considered what it means to attach a script to every field on a layout ?
have you considered that some fields might already have a trigger on them, thus you would need to combine the scripts ?
You could also duplicate layouts (one with edit enabled on fields, one without) but that would mean 2 x layouts.
You could also duplicate all fields and attach a hide when to all of them, but that would mean 2 x fields on the layout and the need to evaluate hiding on n fields.
I don't see how your solution would ever be "simpler" than mine.
can i have sample file plzz
Here is a sample file for my technique.
This is one way of doing this, there are others as well, it all depends on the specifics of your file.
The way I suggested is very simple for a beginner user who just needs a simple solution.
If it's just a simple data entry layout with a couple of fields this technique is super easy to implement and can be added quickly and easily.
There are of course other techniques that can be used and there could be added difficulties, like when there are already script triggers present on the OnObjectEnter event.
I didn't mean to suggest your system wasn't good. But mine could possibly be simpler to implement.
I can't imagine that a user who asks this kind of question has already got a lot of script triggers implemented in their file.
So in short: This is just one suggestion, I'm only trying to help here. There are other ways of doing this that could be better, handier of more appropriate depending on the specifics of your file.
We are all just trying to help here.
Hmm, what happened to the most recommended security method?
Use access privileges for the table where you can control it either for entire table or down to a field, or related data.
No popovers, no special layouts, only the nasty FileMaker dialog "Your access privileges do not allow you to perform this action".
EditNoEdit.fmp12.zip 69.0 K
A lot depends on what the OP's actual need is. If it's just workflow, then interface stuff is fine. If it's actually security, then yes, you need to go deeper.