in my development, I plan to use panels, but depending on the competition the number of series can be different, so is it possible that tabs are hidden depending on the data?
Welcome @Mbk28!
The number of panels shown at runtime can’t be calculated, panels can’t be hidden. There are two ways to achieve your goal:
- use of different panel sets with one panel set shown at a time, using the hide object condition
- use different layouts for panels and buttons on those layouts for switching
A flexible combination is to use sliding panels and a button bar to control which panel is displayed. The button bar segments can be hidden/shown as required. It's simple, effective, and powerful.
2 Likes
Hi @Mbk28 ,
in your initial post you mention Panels and then talk about hiding Tabs. These words designate two different controls in FileMaker that have a similar behaviour.
The Tab control displays one tab at a time, and have a Tab at the top, like File folders used to identify the contents.
Then Panel control displays one Panel at a time, but does not have Tabs at the top to select a specific Panel. Instead, you use dots at the bottom to select a panel, if they are enabled, or slide to the left or right to move form Panel to Panel, if swiping is enabled.
The result you want to achieve is to use @Malcolm suggestion to have a Button bar at the top used to navigate to a specific Panel.
1 Like
These are tab panels. Their display state can be modified. It is impossible to hide individual panels. FM does not provide this functionality. As mentioned above, a workaround is to define different panel controls and to only show the control that has the right set of panels.
we have to maintain a solution that has several hidden 'panels (tabs with no width, labels for a tab are inside a tab (if needed, otherwise no labeling - depending on some other content, a specific panel will be shown).
It is a nightmare to maintain !!
We do also have 'hidden' panels in our solutions, but those are slide elements ('slider-dots' invisible) with a corresponding interface. In each header of a tab are buttons for navigation (selecting a 'panel' by script). You can hide one or another. If it is not a problem if there are gaps between buttons, it's relatively easy
Problem might be during development, one needs to define the tabs as a first step to keep it easier..
The 'Hide Panel' functionality is missing in FM.
For controls with a larger number of panel tabs, I resorted to faking the panel control by using different layouts, one layout for each tab panel. Tabs are replaced by tab look-alike buttons or a button bar (as @Malcolm suggested). The latter has the advantage of offering a hide condition for individual elements.
An additional advantage of the different-layouts strategy is that individual TOGs can be used for each layout. On the downside it takes a lot more code than using native panel controls to write and to maintain. Definitely a workaround, not low code.
People still use tab panels?!? I even have heard of people still using buttons, and not button bar segments. Amazing! The ONLY reason I can see to use a tab panel anymore is that the tabs vary in size based on content, which works really well for displaying "breadcrumbs"
Tab panels can't be hidden, and they can't [easily] execute code when entering a tab. (GetObjectAttribute ; "IsFrontPanel" ) is both convoluted and literals, so brittle from 2 counts.
@Malcolm 's suggestion of a slide panel and button bar segments formatted to look like tabs, is a far better way to go, as you can hide buttons, effectively hiding the "tab", AND you can execute code on the button press.
In defence of tab panels: they implement a particular task easily and do it well. The button-bar and sliding panel combo is much more flexible and powerful. Those benefits come with extra effort and complexity. For that reason, I'll still be opting to use tab panels when I don't need anything fancier.
4 Likes