Probably the preferred method is to use field validations. You can set your validation calculation to something like this:
Case ( Tax_Type = "non-taxable" ; not IsEmpty ( Self ) ; 1 )
in the Validation options for the VAT_Number field. This way, if the Tax_Type field (or wherever the user is setting the "non-taxable" option) is set to "non-taxable", the VAT_Number field has to be populated. Otherwise, it always validates as "True" (which means it passes validation).
Is it really the solution? I hped that there is a way to make the VAT number-field accessible or non-accessible (as it is possible via the Inspector in the layout modus).
Set up an OnEnter trigger on the VAT field to check for taxable. Don't allow entry if not taxable. Couple that with a conditional format on the field to make it look "disabled" if the item is not taxable.
I recall a technique that someone once mentioned a while back, which I have also tried ...
You can do this by using a self realtionship based on the "taxable" status. Display the VAT Number field via the relationship and the field does not "activate" until the relationship is valid.
Does this make sense? It's been a while since I've done it, but it's pretty neat.
Well, it sounds that this will work but I have to find out (myself) how I can implement that. It looks a bit like quite an overhead (Table Occurance, Self-Join etc.) just for this small thing.
It is so unfortunate that we cannot just set or unset the property of that field as it can be done with the Inespector. I hoped that it might be possible...
Apologies. I misunderstood the question.
Wim and Peter both have defined possible solutions. Peter's is often referred to as the "hidden portal trick", where you define a self-joining relationship that joins a constant to a calculated field that toggles based on the value you want. In this way, you can have a single-row portal (with no lines or scroll bars) that points back to the same record. Inside that portal, you place the field you want to "hide". When the relationship is valid, the field appears. When not, it simply disappears.
In this case, you have a key field of some sort on your record. You also define a calculation, like this:
Case ( Tax_Type = "non-taxable" ; keyField ; "" )
Then, you define a relationship between that field and the actual key field:
hideMeKey = keyField
Make the portal based on that relationship and place your VAT number-field inside it. Make the portal slightly bigger (by 1 pixel or so) than the field.
If, on the other hand, you want the VAT number-field to remain visible but not enterable, then Wim's solution is the correct one.
But keep in mind: These solutions are interface-level solutions. You'll need to implement them anywhere the users have access to the field. If they do an import, for example, these interface blocks will not protect the field from entry.
>> activate / deactivate a field
This been one of the requests in our "Wishlist for FileMaker 14" thread. This is so simple in Access and VB... with field.enabled=True
after Mike's explanations I would implement you solution. But the critical step is to "not allow the entry". How ist this set? Which script instructions ist to be used for that?
this would be very helpful. Why not FM 13?
thanks for the lenghty explanation; would tend to Wims solution. Your hint regarding the interface-level is good (to learn more...) though in my case this is no problem.
Well, sure, it can be 13. We weren't sure there is going to be a FileMaker 13, as the number is considered unlucky.
An odd cultural quirk, of course, but here in the U.S there seems to be no lack of those these days.
Not sure this is a whole lot different than in FileMaker:
1) In Access, you set a property on the field object in the form.
2) In FileMaker, you set a property on the field object in the layout.
If you want that property to change dynamically:
1) In Access, you write some VB code that detects the conditions and you change the property.
2) In FileMaker, you set a Script Trigger (a property on the field) and write some code that detects the condition and causes something to happen.
In principle, they're largely the same thing; it's simply a matter of a little different approach.
ven though I am quite new in Filemaker - I doubt that this works the same as Filemaker has in some ways certain very own approaches. And if it would be as easy as that I would (hopefully) found out already. But - even the answers here (self-joing etc.) - show that Filemaker does not make it that easy...
Hi, Mike... set me straight if I haven't got this correct, but my issue is that in FileMaker, there is no field property called "enabled" that can be toggled via a Script Trigger.
In Access and VB, when set to FALSE the enabled property "grays out" a field, and prevents entry into the field.
On the Mac side, Objective C also has an .enabled property for buttons, and text fields.