1 of 1 people found this helpful
I would like to make a field not accessible if a certain condition is met.
Use conditional formatting to provide visual guidance. Dim the text labels of fields to ignore and increase the visibility of fields to complete so users can easily see which fields to move to.
If you must have strict control of the input use field validation rules. For example, the validation rule for "maiden name" might be:
(gender = "female") xor isempty(self)
One method I use is to make any field I want inaccessible into a button. I then script that button to check a variable and if the condition is met I use the go to field to place the user in the field. For instance in your solution you could set a script trigger on the gender field and then use that variable to allow access to the maiden name field. I also like to incorporate the visual guidance as Malcolm mentions above.
Edit: Correction...You would not need a variable as you should just use the gender field to perform the check. Haven't had quite enough coffee yet this morning.
1 of 1 people found this helpful
You could also use the hidden portal trick to hide the field completely. This involves a self-joining relationship based on the condition you specify and a one-row portal with no lines. Place the field inside the portal row. If the condition is true (or false, depending on what you want), there's no related record. Hence, it becomes impossible for the user to click in the field, because it doesn't exist.
I'm generally not a big fan of placing business logic at the database schema level. Field validations fall in that category. If you do use field validation do make sure to use a lot of error trapping handling. Especially on server-side scripts and imports where the normal validation failure message can not be shown to the user.
An alternate approach is to use OnEnter script triggers. The downside is that you have to set those per field per layout where needed, but it does give you more granular control.
This is a technique with a solid history of application, but I would suggest that filtering the portal rather than the relationship might make for a lighter-weight relationship graph and keep more business logic out of the schema. That way, you can accomodate any number of rules for access to fields in the same table with only one self-join relationship based only on the primary key. Since the relationship would only ever be matching on one record (a record that is already loaded from the server to display in the local TO for the layout), this doesn't run afoul of the potential performance issues of filtered portals on large record sets.
Hey, nice update to the technique! Store that one away ...
A portal can hide an object, but it cannot put another object in its place. A tab control object, OTOH...
A portal can be used to put different "fields" (from the user perspective) in the same location in the case of an EAV model. A common simplistic example is showing different types of contact information (phone, fax, email, website, etc.) in a single portal. However, I usually don't go through the effort of implementing an EAV model unless there's a need for an arbitrary and user-definable number of "fields" (attributes); and a tab control does still make it easier to display different styles of input control in the same location.
Jeremy reminds us that at the portal filter level, we can have flexiblity in displaying what we want in the portal; and that performance can still be good if the underlying relationship limits the number of related records.
I notice that for an allow-creation relationship, a portal filter can be defined to ONLY show the empty row.
But I wonder if the opposite can be done. That is, if a relationship allows creation of related records, can a portal filter be set up so that it does NOT show the empty new-record row?