How to lock a field based on value of another field?

[JariV]

Hi,

There is probably an obvious way to do this, but since I couldn't figure it out myself, here it is:

How can you prevent users to change a value in a field, say Time1 [time], based on a value of another field, say Checked [number, 0/1]? (Checked[0]=modifiable, Checked[1]=not modifiable)

Jari V

[Raybaudi]

For example with a script...

1) Create this script:

If [ not IsEmpty ( Checked ) and Checked = 0 ]

go to field [ Time1 ]

End If

2) Make the field Time1 a button that fires the abowe script and set it "not enterable in Browse Mode"

[JariV]

Thanks a lot, it works nicely.

The "Go to field" script step seems somehow circumvent the "not enterable in Browse Mode" setting, because you can enter data despite of that?

I have 10+ fields in 10+ layouts (and some in portals) that need to be locked - I'm wondering if it is somehow possible to implement that locking functionality through the field option/validation setup, so that lockable fields would be automatically lockable where ever they are displayed?

Jari V

[David Jondreau]

Let Checked = 1 mean modfiable and Checked = 0 not modifiable.

Set field validation = Checked.

Users can enter the field, but if they try to change it, they'll get an error message.

[JariV]

Thanks, this seems to work in that sense, that it ultimately prevents the user making changes, but it first allows the user to enter new values and only upon exiting the field, it gives the user two FM error dialogs (in installed version's language) to revert the changes.

As this solution is used in three different languages (I have a separate language database for script error/dialog messages, field labels etc.), a locking solution that would not fire internal FM error messages in case of conflict would be ideal, but that may not be possible through making the field locked using field option/validation setup?

Jari V

[Raybaudi]

Another way to lock fields is by using Privileges...

You can create a new privilege set for a new account that can lock one or more fields.

Lock_Unlock_fields.zip

[JariV]

Thanks again,

The solution in question is run on a server by multiple users, whose usernames are used in various export and printing scripts, so re-login as other user, once the records are marked checked may not work well in this case.

In terms of functionality (from the users point of view), your first suggestion works perfectly (also an error message can be easily incorporated).

As it does not seem possible to create similar function using field option/validation setup, my best option seems to be to just create separate scripts for all fields to be locked, and apply those to lockable fields in all layouts.

Thanks a lot for your help.

Jari V

[David Jondreau]

If plugins are an option, zippScript or EventScript will allow you to run a script on field entry, which can be used to block access.

[comment]

As it does not seem possible to create similar function using field option/validation setup

Why not? It may not be the most pleasant experience for the user, but it is certainly possible. Validate your lockable field by a calculation =

not Locked

where Locked is a number field (0 or empty = unlocked, any other number = locked)

[JariV]

Thanks,

Yes, this option does prevent the user from changing the values in the locked fields, but unfortunately it also triggers two FM error messages (which are in the installed versions language).

In the above quote, in my mind I was thinking with "similar function" the user friendliness of the first suggestion using a script (if the field is locked, the user just can't go to the field), but that was not too clear there, sorry for that...

Ideal (but maybe impossible?) solution to this would be, that the field locking function could be defined within the field options setup, but in a way that does not trigger internal FM error messages if the user tries to change a value in a locked field.

Anyway, thank you all for your help with this.

Jari

[Genx]

It may not be the most pleasant experience for the user

Lol, aint that the truth.

I'm with Daniele, the easiest way is probably with a script... even if you end up writing 6 or 7 of them...

[JariV]

Well, after counting, it is actually more like 56 of them (which is why I've been desperately trying to find an alternative..).

Luckily there is a copy/paste function, it makes it a bit easier...

Jari V

[Genx]

Well in that case I would go with the other suggestion of using a plugin to trigger a script to commit the record and show a custom dialog when the user enters the field -- much prettier than FileMaker's validation functions - only 1 script.

www.softs4humans.com (eventscript)

www.myFmButler.com (doscript)

I don't know the link for zippscript though i do have a copy -- It's good as well.

Are you running FileMaker 8 or 8.5? Just sometimes people forget to change it...

[comment]

I am with Daniele too - I was triggered by "does not seem possible". But now that Jari explained he too meant the user experience, I believe we are all on the same page. Although I still don't understand why there should be TWO error messages, instead of just one - and that one can be customized as well.

And I believe one (long) script should be able to accomodate all, using a script parameter.

In any case, here's yet another option, using a paraphrase of the 'visibility' trick.

LockFields.fp7.zip

[Genx]

You know what Michael?

That is actually quite cool! I've seen a lot of the techniques with the visibility trick but could never really be bother looking at any of the files lol. Very straight forward.

Only real drawback would be if each of the fields was based on a different condition in which case you would have a fair few extra relationships... but in truth that's probably in all the techniques

[JariV]

Are you running FileMaker 8 or 8.5?

I'm still running FM8. Does 8.5 have something new that could be useful here?

I still don't understand why there should be TWO error messages, instead of just one - and that one can be customized as well.

I'm getting first an error "Time1 is defined to countain only specific values. You must enter a valid value." [Revert Record/OK] (even if a valid time is entered). Then, after clicking Revert Record another error message "Revert all changes to this record since it was last modified" [Revert/Cancel]

If you could reduce the number of error messages to just one, and then customize that, that would actually be quite a simple way to implement a reasonable user-friendly locking feature. The question is, how can you customize internal FM error messages?

And I believe one (long) script should be able to accomodate all, using a script parameter.

.

I'm still quite a novice with scripting, could you point me somewhere, where I could find more information on using a script parameter?

In any case, here's yet another option, using a paraphrase of the 'visibility' trick.

This one seems very clever, and potentially much less work than creating individual scripts for each lockable field. However, I didn't quite understand the mechanism, that determines which one of the two lockable fields (on top of each other) is active?

Again, thanks a lot for your help.

Jari V

[comment]

Then, after clicking Revert Record another error message "Revert all changes to this record

Ah, OK - that IS two messages. I use validation so rarely, I haven't even noticed. That is actually a good thing, because reverting will cancel ALL edits you have made to the record - not just the one that triggered the validation.

You can customize the first message only, by checking 'Display custom message...' in the Validation dialog. And if you also uncheck 'Allow user to override...', the dialog will be less confusing, IMHO.

The mechanism of the demo is simple: one of the fields (the one that belongs to the 'local' TO) is non-enterable. The other field, from the related TO can be entered - but when there is no related record, this field does not exist.

The script to allow/disallow entry into individual fields should also be quite simple.

LockIndividualFields.fp7.zip

[Raybaudi]

Hi comment

thank you for an example of my discovered bug !

BTW: On my windows pc I delete the "Beep" step, as it seems to slow too much the script.

[JariV]

Thanks a lot for all the explanations and sample files, they were very useful.

I will now play around with these to see which one is most suitable for this solution.

Jari V

[mhari]

it's more useful guys....

[mhari]

It's good to see your efforts are converted into results. But can you please suggest me some advacnced script concepts book or a link to download the file (from any forum).

Hari

[Ballycroy]

Hi Comment:

In you example file "LockIndividualFields.fp7.zip"

How did you format that number field "LockedR".

Format as Boolean

Show non-zeros as:

and

Show zeros as:

Those characters look like graphics

Are these private use unicode characters for the Webdings font.

Beyond knowning the term "private use" I have no knowledge on how you created these.

Can you explain?

[comment]

They are Webding font characters. I don't know about private use - I just inserted them using the Character Palette.

[Ballycroy]

Thanks Comment:

I should have looked more closely at the Character Pallette!

Edited February 15, 2008 by Guest

[Jimjmn]

Could you please explain for my why I can't get this example (LockFields.fp7) to work it the global fields aren't present on the LockFields layout? Thanks so much

[comment]

There are no global fields in that file (and no LockFields layout, either).

[sccardais]

Ah, OK - that IS two messages. I use validation so rarely, I haven't even noticed. That is actually a good thing, because reverting will cancel ALL edits you have made to the record - not just the one that triggered the validation.

You can customize the first message only, by checking 'Display custom message...' in the Validation dialog. And if you also uncheck 'Allow user to override...', the dialog will be less confusing, IMHO.

The mechanism of the demo is simple: one of the fields (the one that belongs to the 'local' TO) is non-enterable. The other field, from the related TO can be entered - but when there is no related record, this field does not exist.

The script to allow/disallow entry into individual fields should also be quite simple.

Dear Comment / Consultant

 

I love the approach you took on locking individual fields but I'm having trouble adapting your approach to my database. I'm using FMP Pro 13 Advanced.

 

Using your sample file, "LockIndividualFields", I added one field. I added this field to both layouts. I copied the lock icon for Field 5 and changed the parameter to 6. I also increased the max repetition on field LockedR to 6 and checked (several times) the scripts and button setup for the new field. 

 

When I click on the lock icon for the new field, nothing happens. However, when I click on the lock for field 5, it toggles field 5 and the new field 6. 

 

I know this should tell me immediately what's wrong but I've checked and rechecked. No revelation yet.

 

Can you explain the steps needed to adapt your field locking solution to an existing FMP file?

[comment]

Can you explain the steps needed to adapt your field locking solution to an existing FMP file?

 

Sorry, no. Demo files are posted in order to avoid lengthy explanations. Plus I would have to go back and relearn what went on here. Just give yourself more time.