Showing/Hiding Layout Elements
Showing Hiding Layout Elements
In addition to presenting various windows for your users, you may at times want interface objects and other layout objects to appear and disappear (or change) depending on various conditions. A simple example might be a Delete button: Not everyone who uses your database should be given delete privileges. If you have placed a button on your layouts for deleting records, you'll need to either trap for an unauthorized attempt to use it (and likely present a graceful "you're not permitted to do that" message with FileMaker's security settings), or craft separate layouts that offer both the full and the limited functionalities you need.
That's the first low-tech approach: Create different layouts that look nearly identical but offer one without a Delete button to users without that privilege.
The downside to this multiple-layout approach is that you will need to build and maintain multiple layouts so that the time you spend making changes will be multiplied by however many layout versions you have. This approach also requires a fairly sophisticated navigation scheme in which you control which version of a given layout a user is presented. In many regards, maintaining multiple versions of a layout is an impractical solution.
To deliver the functionality of having layout objects appear and disappear, remember that portals can contain not only fields, but buttons as well. You can place layout objects on a portal row, set the portal to display only one row, and control the availability of the layout objects within that portal by controlling that portal's respective child record's relationship to the parent record from which it is being viewed.
You can implement this sort of functionality in your database solution in various ways. The simplest approach is to create an on/off resource table with one record in it (simply a table you'll use as a developer to store internal logic). When necessary, simply relate to that record by populating a global field in the current table with a constant that matches the same in the resource table. You could control the global match field by script, toggling it on and off as part of your navigation or as part of a user's other actions. You could also create a global calculation based on checking certain privilege sets (including an extended privilege). Refer to Figure 13.16 for an example of a Delete button being controlled by a relationship and disappearing when appropriate.
Figure 13.16. By placing a button within a one-row portal (set to appear transparent), you can create a place where layout objects appear based on a relationship.
To implement one example of this technique, follow these steps:
|
1. |
First create an extended privilege meant to control the appearance of a Delete button (as shown in the example in Figure 13.16). In this case, name it portalDelete.
|
|
2. |
You will be controlling the appearance of your button objects by controlling whether a related record is available within a portal. To tie this to an extended privilege, first create a match field (called _ka_PortalControl) and set it to be a calculation field with the following formula:
Case ( PatternCount( Get(ExtendedPrivileges); "portalDelete" ) = 1; 1; 0 ) Set the field to be unstored and to be evaluated on demand. Make sure that it is in the table from which you intend to view this portal.
|
|
3. |
You now need a record to which to relate. Create a match field, _ka_PortalControlconstant, to a resources table. Make sure that there's at least one record in the table.
|
|
4. |
Create a relationship from the table occurrence that is showing data to your resources table occurrence.
|
|
5. |
You can now place a portal, showing one row, on the layout in question, tie it to the resources table occurrence you've created, and then place buttons as you need within the one-row portal.
|
When you assign the portalDelete privilege to users, they will see the Delete Record button shown in Figure 13.16. If you have not enabled the extended privilege for the currently logged-in user, the user will see only a blank area on the screen. If the user clicks in that area, nothing will happen.
Place whatever layout objects you need in the single portal row. Because you likely won't be drawing from any data in the resources table, you need only one related record. Note that because these are layout objects, they will appear on every related row in a portal. It actually doesn't matter how many related records are in the resources table as long as there's at least one.