I don’t think I’ve ever user this technique to get “better tabs” than FileMaker provides out of the box though. I use this technique when I need a little dynamic behavior on the layout. For instance, in one project I’m working on now, we’re building a layout that combines functionality from half a dozen places in one streamlines UI for a particular group of users. As such:

1: The layout is really cramped for space.
2: The layout is complex (lots going on).

In one area, the user make a choice which influences the UI for a portion of the screen. The choices they make early on change which portals, buttons, and text we display further down the screen. We really had three choices in doing this:

1: Use a separate layout for each variation (there are three) and switch as appropriate. Because this layout is complex, that would mean maintaining a lot of duplicated complexity across three layouts (or possibly four, since there’s the “not yet known” state as well).

2: Use a “wizard” type system. This just introduces extra clicks, and streamlined entry is this layouts Raison d’être. Users will be working through this process many times a day.

3: Use real tabs. The problem with this was subtle, but it just wasn’t natural. We were asking the user a couple of questions, essentially, and it didn’t feel right to work the answers into tabs.

So we opted instead to put each version of the changing portion of the layout into a tab panel, hide the tabs, and switch to the correct version automatically as the user works with the screen.

This sort of thing comes up now and again, and in case like this we use the hidden tab technique. It is definitely a judgement call, though.

Also, we’ve taken to “labeling” our layouts when we do this kind of hackery, which is a technique I’ll write up some time.

Thanks, and we love your blog,

Geoff

1: Remove the Emboss effect
2: Set the line thickness to 0px
3: Set the tab width to 0

If you do all three of these and you are on FileMaker 9.0 or later, you will no longer be able to click to switch tabs at all.

Geoff

I’ve essentially been using this technique, but have not been able to solve one thing:

Quoting the note from the post:”You’ll notice that FileMaker still leaves some space at the top of the tab control for where the tabs should be rendered. To eliminate the space as much as possible, set the Font Size on the tab to 1 points.”

Even with width set to 0px and font size set to 1px, there is still a small bit of active space for each tab (about 2px x 10px per tab – depending on font used ) that a user could click. So, an errant click could set off a chain of events that could change the state, confuse the user and potentially break the app. Does anyone know of a way to disable the tabs altogether? I’ve tried overlaying other elements, making those elements buttons, etc. No luck.

While this technique does overcome some limitations of the tab controls, it is definitely hackish. I agree with Tokerud: using the tab controls as intended is the wisest strategy. However, given the small chance of an errant click, perhaps it’s a fine compromise. I guess one could eliminate the chance of an errant click on a tab by increasing the size of the tab panel…

Seems like the only bulletproof solution is the old-fashioned multi-layout tab interface.