Layout Views: Is their a function that can determine if a particular "view" has been made available (or not) by developer, or control it through Privilege Sets?

[dmontano]

Hi all,

My current "design" of a button bar (with its three relevant buttons) that would allow a User to…

• View as Form
• View as List
• View as Table

…has me scratching my head.

JUSTIFICATION FOR THE FUNCTIONALITY

The reason for building this View Layout button "functionality" is rooted in my quest to Hide Status Toolbar. Since I am hiding the status toolbar, I have been rebuilding the elements of the Status Toolbar that should be made available to Users (and to me as a "developer").

WHAT I CURRENTLY HAVE BUILT

I have the buttons and the scripts working just fine that go the various Layout Views. 

See screenshot:   3_button__button_bar__layout_mode.png

In addition, I am hiding the particular button as a possible selection if that button matches the layout view the User is currently viewing. I am achieving this by using "Hide Object When". For example: 

• If User is currently in "Form" view, the hide calculation for the "View as Form" button is:   Get(LayoutViewState) = 0
• If User is currently in "List" view, the hide calculation for the "View as List" button is:   Get(LayoutViewState) = 1
• If User is currently in "Table" view, the hide calculation for the "View as Table" button is:   Get(LayoutViewState) = 2

 

See screenshot:   3_button__button_bar__browse_mode__1_button_hidden.png

WHAT I CAN'T FIGURE OUT IS "EITHER" OF THESE TWO SCENARIOS:

Scenario 1:

How to "hide" a particular button (View as Form, View as List, or View as Table) based upon a User's privilege set assigned to them. I can not find anything that would give me the ability to control which "views" I can make available or not available to Users in the privilege settings. I see that one can control access to a particular layout, but not the more specific area of Layout Views: or have I missed that setting somewhere?

Scenario 2:
How to "hide" a particular button (View as Form, View as List, or View as Table) based upon if the Layout View option is disabled by the developer to begin with.

See screenshot:   layout_setup_dialog.png

Is there "function" that would allow me to test if a layout view was disabled by the developer? If so, I would be able to set a hide condition.

Is there a function equivalent to my MAKE-BELIEVE FUNCTION I'm calling Get(LayoutViewEnabled)?

Which would maybe return a "0" for Form; a "1" for List; and a "2" for Table.

MY HUNCH

Neither of these two scenarios can be achieved with the tool set we currently have with FileMaker.

MY DILEMMA

If I can not achieve the ability to control what Views a User has access to, do I just leave the three options to View as... the way that it is?

If I do so, Users can enter any of the views even if, I as developer, have deselected the option to "View as" in the Layout Setup up dialog settings.

Any help is appreciated.

Edited July 5 by dmontano
Title Clarification

[comment]

4 hours ago, dmontano said:

Users can enter any of the views even if, I as developer, have deselected the option to "View as" in the Layout Setup up dialog settings.

When I read this, I was taken aback: I thought surely a button cannot override the layout setup and allow access to a view which the developer has disabled??

But you are right, it does do exactly that. I consider this a bug.
 

I think you have no choice other than to customize the bar for its specific layout. It's not like we have the option to share objects across layouts anyway.

 

Edited July 5 by comment

[dmontano]

1 hour ago, comment said:

I consider this a bug

I agree. 

What I find interesting is FileMaker itself - when Status Toolbar is active - dims any of the "views" that have been disabled. So there is clearly an underlying mechanism that does this - its just not available in any way that I can find. If FileMaker created a function that gave us the ability to test for whether a particular view was enabled or disabled would be good.

1 hour ago, comment said:

I think you have no choice other than to customize the bar for its specific layout.

I have to rethink what I could do in this instance. I do have another button bar that only shows if the User has "Full Access" privileges in order to get to the "back-end" of "things".

1 hour ago, comment said:

It's not like we have the option to share objects across layouts anyway.

Could you explain this a bit more so I understand? I think the "operative word" in your statement is "share".

I am currently building what I call a "function bar", that when complete, I will "copy and paste" on all of my layouts. In order for this to work, I have been "parameterizing" these buttons and building scripts to work with these parameters: this has been a long and arduous task (for me). I don't think your statement applies negatively to what I am trying to do, but rather highlight that "if" I need to edit this "function bar" of mine, that I will need to edit all instances of it.

If I am correct that the operative word is in fact "share", I wholeheartedly say that I wish FileMaker had the ability to allow us to build an Object in one place, and deploy it in multiple places. If a change is needed, we change the "one" object" and all instance of that object are updated.

I have attached my "function bar" (object) in its current development state (using conditional formatting "RED & BOLD" that only an Admin can see to highlight which button/script will need its parameters customized per layout), and a manually added text status below each button of DONE if I think I have finished the segment. 

Again, thank you for your input.

[comment]

1 hour ago, dmontano said:

I wish FileMaker had the ability to allow us to build an Object in one place, and deploy it in multiple places.

Yes, that's exactly what I meant. You are not alone in that wish, it's been often suggested (usually as a type of a layout part).
 

As a side note: while I often switch between form and table view in solutions for my own use, I would almost always create separate layouts in solutions designed for others. So there would be a button for "detailed view" on the list layout and a "back to list" button on the form layout.

Also keep in mind the possibilities offered by list-detail layouts, popovers and card windows.

 

[dmontano]

On 7/5/2025 at 1:42 AM, comment said:

Yes, that's exactly what I meant

Hi Comment, thank you for clarifying this.

On 7/5/2025 at 1:42 AM, comment said:

while I often switch between form and table view in solutions for my own use, I would almost always create separate layouts in solutions designed for others.

I'm now leaning strongly on:

1. Build a FORM view for each layout in my solution that both USERS and ADMINS will access; but hide any object that should only be accessible to ADMINS. I anticipate not really needing much to hide and will probably put that "hide" data in a button bar with a popover button dedicated just to ADMINS. That way it's really just one object to hide.
2. Build a TABLE view for ADMINS only: but allow Table view for those with [FULL ACCESS].
3. Build LIST view where needed.

 

On 7/5/2025 at 1:42 AM, comment said:

Also keep in mind the possibilities offered by list-detail layouts.....)

I believe I am currently utilizing what you are referring to by "list-detail layouts" as shown in attached screenshot titled "list_detail_example.png"

 

On 7/5/2025 at 1:42 AM, comment said:

Also keep in mind the possibilities offered by ........, popovers and card windows.

I believe I am currently utilizing what you are referring to by "popovers" as shown in attached screenshot titled "popover_example.png"

 

I "think" you may be pointing out that I might be able to use a POPOVER or CARD WINDOW in which to show a LIST view-type of presentation? I may be assuming a bit much here.

Thank you again for your help, much appreciated.

[comment]

4 hours ago, dmontano said:

use a POPOVER or CARD WINDOW in which to show a LIST view-type

Actually, it's quite the opposite: you would have a List layout to show a bunch of records (typically non-editable). Then you use a popover or a card window to drill into a specific record for more details and/or editing. It's functionally similar to list-detail layout but you have more space to work with, since the detail temporarily conceals the list.

 

[dmontano]

21 hours ago, comment said:

Actually, it's quite the opposite

Ok, now I understand: thank you for the clarification.