Button Bar is not just a superset of Button

[Mark Scott]

I don't know about you, but when I first saw the Button Bar demoed, I figured it was just a quick, handy way to add a group of individual, potentially but not necessarily related, buttons, and keep them conveniently grouped.  Nice, but nothing special; I was a bit underwhelmed!  In fact, believing it to be only a convenience thing, I figured that I might even get in the habit of adding "single-segment" button bars in lieu of traditional buttons (with the added bonuses of calculated labels, available only for button bars, as well as being able to switch between action and popover buttons).  Turns out the button bar is a somewhat different animal, in ways that make it ideally suited for use as a navigation tool.

The key difference is this concept of "Active Segment."  Generally, one segment is active at any time.  Even if you specify "None" for the active segment in the button bar setup HUD (or a calculation that would seem to result in no segment being active), as soon as the user clicks on a button segment, it becomes active.  This has a couple ramifications.  First, since the active segment can be styled differently in the Inspector — "Active" is now a state in the state popup menu at the top of the Appearance tab — you can choose styling that shows the user which segment is active, ideal for navigation bars.  (Note that you can even style the button icon, another new-to-14 feature, to respond to state!)

Second, and importantly, once a segment is active (whether through designation in the button bar setup or user click), it no longer responds to other states, such as hover or pressed.  This makes total sense for a navigation bar:  because the "active" segment is generally the current layout (or current slide panel, etc.), it is essentially unavailable to the user to click at this moment, thus no hover or click state.  Clicking on a different segment changes the active segment and frees the previous segment to once again respond to hover effects, etc.  This behavior, however, explains why you probably won't want to use a single-segment button bar in lieu of a traditional, stand-alone button.  Buttons and button bars are different layout objects serving different purposes.

So, on digging a bit deeper, I've become more excited about button bars than I was when I first saw them.

BTW, a great demo on how to use these new objects for navigation can be found in the FM14 Training Series Advanced series and accompanying demo/practice files, complete with associated scripting, conditional formatting, etc.

hth,

Mark

[Kris M]

Soliant's Martha Zink has a nice vid of button bars

http://www.soliantconsulting.com/filemaker/solianttv/unboxing-filemaker-14

Just wish they would expand/collapse based in hide condition

[Ocean West]

one thing that is nice is that you can change your mind between a Button and a Popover, should your logic change and you need more real estate.

however be carful gong from popover to button as when you switch and save the layout you will loose the contents of the popover without warning.

unlike a single button you can't use the calc engine to dynamically title the button as you could with a single segment button bar.

 

[Mark Scott]

one thing that is nice is that you can change your mind between a Button and a Popover, should your logic change and you need more real estate.

however be carful gong from popover to button as when you switch and save the layout you will loose the contents of the popover without warning.

unlike a single button you can't use the calc engine to dynamically title the button as you could with a single segment button bar.

 

​Indeed!  Those are both features that I hope they bring over to regular buttons.  In the meantime, we can, of course, use merge variables or calc fields to dynamically label buttons, but being able to enter a calc right into the button setup is a nice feature of button bars and would be equally nice for stand-alones.  On the other hand, a button bar segment labeled by calc just says "calculation" in layout mode, which, although understandable — what else could it say? — is not always as helpful as seeing a real label.

I think in cases where one really wanted to use a calculated label on a single button (and for whatever reason didn't want to use a merge variable), you can override the loss of hover/pressed effects after activation with a script trigger to deactivate the button.  I'll have to test it once again to confirm, but I think you can use an OnObjectExit trigger that simply refreshes the object (assuming the button bar setup specifies "None" for active segment).  That allows a single-segment button bar to stand in for a regular button, but at the expense of one more trigger to keep track of.

 

[Mark Scott]

One more difference between button objects and button bars is that the formatting is a bit more complex for the latter (and they don't share object styles within themes).  With button bars, both the bar (as a whole) and its segments can be styled independently of each other, which is a good thing.  For example, you can apply lines and corner rounding to either or both, even if it's just a single-segment variety.  Box shadows, otoh, are more restricted:  an inner shadow can only be added at the segment level, while an outer shadow can only be added to the bar as a whole.  Just a couple things to keep in mind whether you are using a button bar for navigation or as a replacement for a regular button.

[James Gill]

I just found out that you can complete hide a button bar segment and have the rest of the buttons bar element resize itself to take up the space of the hidden button.

No more having to worry about Layout consistency issues when conditionally hiding elements if a user doesn't have permission to access that element!  My only gripe is that, at least when the buttons are assigned vertically, the button element itself retains its original sized and doesn't keep the relative segment sizes consistent, but I don't see any issue with that with for horizontally aligned header-based navigation.

Edited May 19, 2015 by James Gill

[Agnes Riley]

Is anyone having an issue with the inability to specify the Active Segment via calculation? Even if I type the name of the actual button exactly it doesn't change the color, even though it is specified in the style properly. Hover works, selecting "Companies" manually works and the popover button changes color when activated by clicking on it.

[innodat]

Is anyone having an issue with the inability to specify the Active Segment via calculation?

​I have a similar issue: if I specify the segments of the button bar to be pop-overs, the bar looses the active segment, as soon as I click on a different segment. This might seem logical at first, however, if I'm only viewing the content of a popover button, but don't execute any scripts/don't leave the layout, and dismiss the pop-over, I would expect the original segment to active once again. This is not the case. It no longer indicates anything.

I thought I could use the active segment function to indicate the current layout (the layout to which the active segment belongs to). But apparently that doesn't work like that.

Unfortunately, there are no script steps to influence the state of the bar, otherwise the state could have been restored upon leaving the pop-over button by means of script-trigger.

Edited May 28, 2015 by artvault

[Claus Lavendt]

When you specify the active segment, you need to use that segment's object name.

So, select each segment and name them. Then your calculation of active segment will work.

[Claus Lavendt]

And, if you calculate the active segment, you might need to throw in a Refresh Object script step to some operations, if you do not change layouts.

You can definitely use the calculation of active segment to indicate which layout you are currently viewing. That is a great thing, when using it for navigation menus.

[Agnes Riley]

Thank you. I just learned that myself. It is a bit counterintuitive because the segments are already named.

 

And now my calculation works well. 

[Mark Scott]

Daniel Wood has posted an excellent article on building abstracted navigation bars using FM Button Bars.

Mark

Edited May 29, 2015 by Mark Scott

[innodat]

@Mark Scott - thank you for the tip! Fantastic article indeed. Very informative. Too bad about the icon limitation...

[Mark Scott]

​I have a similar issue: if I specify the segments of the button bar to be pop-overs, the bar looses the active segment, as soon as I click on a different segment. This might seem logical at first, however, if I'm only viewing the content of a popover button, but don't execute any scripts/don't leave the layout, and dismiss the pop-over, I would expect the original segment to active once again. This is not the case. It no longer indicates anything.

I thought I could use the active segment function to indicate the current layout (the layout to which the active segment belongs to). But apparently that doesn't work like that.

Unfortunately, there are no script steps to influence the state of the bar, otherwise the state could have been restored upon leaving the pop-over button by means of script-trigger.

​Hi Art,

In order to restore the default active segment upon exiting the bar, the trick is to name the bar as a whole in the Inspector, then either include a Refresh Object step in your script (if you're running one) or (in the scenario you describe where the button opens a popover without running a script) use an OnObjectExit trigger with the Refresh Object step.

Note that the object that gets named and refreshed here is the whole button bar, not the individual segment.  (You can name the whole bar, as well as any or all individual segments in the Inspector, but only when the former is used as the Refresh Object target will you see the desired result of the bar's default Active Segment setting being restored.)  

Apparently — and, on reflection, it makes sense — the default Active Segment specification is an attribute of the whole bar, not any particular segment.

One additional pointer is that, if your goal should happen to be to have no segment "Active" then, for this technique to work, rather than specifying "None" for Active Segment in the Button Bar Setup, specify a calculation that returns "False." This technique works great for restoring the Inactive state of a "single-segment" button (and thus restoring the ability of the button to respond to hover and pressed states), when using a single-segment button bar in lieu of a traditional standalone button.

hth,

Mark

 

[innodat]

Your explanation makes me feel dimm in the best way possible. It didn't occur to me that refreshing the object (in this case the bar) would return it into its original state, which has the active segment highlighted. So simple. Brilliant. 

[Agnes Riley]

Am I missing something?

I can't attach a script trigger to the entire menu bar. Fine.

If I attach a trigger to a popover button the script attached doesn't run when clicking off of it, aka exiting in my book. 

I only have scripts attached to the list on the popover, not the actual popover button itself. When the actual script runs an I arrive to a new layout, my button bar is refreshed, so have no issues there.

http://cloud.zerobluetech.com/image/2d3X0W2S330h

 

[Claus Lavendt]

Agnes, you can attach a script trigger to the actual popover panel (not the button)

e.g. OnObjectExit, which triggers a script with a refresh object step, that refer to the entire buttonbar itself.

That will work for resetting your buttonbar. e.g. not having the popover button selected.

If you set a script trigger to a segment, it will trigger on selection of the segment. e.g. OnObjectEnter / OnObjectExit.
Since you do not modify or save anything on the object, when you click or select it, these triggers are not really relevant.

So, any script associated with a button in a button bar, should have a refresh object step, unless the process triggers a window refresh, such as navigating to a different layout.

For popovers, set the trigger on the popover panel itself.

Hope this helps

[Agnes Riley]

Thanks, Claus, but that's not triggering the script it either because I haven't actually clicked to select a sub-menu item, I just hovered after clicking the popover button. Had I clicked it I would've arrived to another layout, which, again, refreshes the button bar.

Thanks,
Agi

[Claus Lavendt]

If I get it right....

Click on a segment in a buttonbar, which is set to be a popover.
The popover opens, so you can see your submenu.
When you click outside the popover, resulting in the popover to close, you want the buttonbar to reset.

If this is correct, you can set an OnObjectExit script trigger on the popover panel itself (not the button) that refreshes the buttonbar.

[Agnes Riley]

And the idiot award goes to me. I blended my button on top of the popover so well that I assumed that I was selecting the popover, when I was selecting the button. Problem solved. Sorry for wasting your time, Claus!

[LaRetta]

This thread has helped me a lot, thanks very much everyone!

[LaRetta]

Another nifty thing about the button bar is that you can hide individual segments but also select and hide the entire bar separately.  For example, you may select the segment with a 'find magnifying glass' and hide it in find mode and still select and hide the entire bar when you wish to prohibit a User from other actions such as during a record edit.