You user interface design actually seems less flexible than using portals. Keep in mind that while the default format for a portal row produces a simple tabular arrangement of rows and columns of data, this is not the only option for a portal.
Be that as it may, you haven't explained exactly where you need help here. Go to Object is the script step to use to put specific tab panels or slide control panels in front. It can also be used to open popovers.
Just a couple of comments at this stage—
Re: "When the user selects a different tourist category (1st level tab), I'd like users to be automatically directed to the same geographic area (2nd, 3rd, and 4th level tabs)" Sounds like the tourist category tabs should be level 4 instead of level 1.
Re: "Even though a user might spend $100 for an excursion or dish out $200 for a hotel room, s/he might only be willing to pay $35 for dinner." How on earth do you think FM is going to be able to guess at that and the navigate appropriately?
You're right about changing the order for the scenario I presented...the
top level placed at the bottom would certainly be easier. Remember this is
a mock scenario that's greatly simplified just to get some guidance. Let's
suppose you had a module (three or four levels deep) embedded on a tab
panel...with a slider control "at the end". How would you approach this?
Regarding the slider navigation, I mentioned there's a pricing scale for
each category (rated as 1, 2, 3, 4 or 5). Any reason why a static rating
scale such as this wouldn't work?
Yes, if you have the category as the fourth level, then users can easily switch from Hotel to Restaurant to Excursion to Event without altering the geographical context. So far so good.
Guessing from your layout image I assume that the five slide panels are for the different levels of restaurant in Beverly Hills, and you are showing the fourth panel because that is the one selected for restaurants below. That seems a reasonable enough approach to me. To automate selection of the right panel, object naming is the key, as indicated by Phil. Each slide panel would need an object name, since you have sliders on each tab—which might simply be R1, R2, etc. Then using an OnPanelSwitch script trigger you can run a script which would select the appropriate panel according to the selector preference.
My solution actually has five levels of tabs panels and one slide control
embedded in the final control panel. Actually, I am using portals on each
You still might be asking, "Why so many tab panels rather than setting up a
portal?" Well, unlike the simplified example I provided, my solution is
more of an authoring tool. And these "tools" are organized by
topic/subtopic/sub-subtopic, etc. With so many tools the users will likely
prefer a persistent albeit multi-level menu structure over a portal.
Before sharing my issue, I was concerned that I might need to list the
entire "path" for Filemaker to find the embedded slider on a given layout.
Looks like I was over thinking this as only the name of the deepest
embedded tab panel or slider control is required.
At any rate, I initially suspected that GoToObject would be the right
function to use. With that advice as well as great suggestion from
Keywords' on using OnPanelSwitch, I can make this work just fine.
Ok, but I don't know if you realize why I'm telling you that portals can be more flexible than tabs or slide controls. You will be setting up a set of these objects and each has a fixed number of panels. If the number of panels should change--either because of a change of context (One set of values necessitates 8 panels and a different set only uses 4....) or because you find the need to change them in the future as either the project changes or your understanding of what works best changes.
With portals, you don't encounter those issues nearly as much.
That said, I'm now going to argue against my own comment just a bit in order to provide a more complete picture:
Slide Controls can be used to provide a theoretically endless number of "apparent panels" in a kind of "horizontal portal" with a bit of scripting slight of hand. I use this on iOS devices with a calendar widget that lets me enter dates without using the iOS based date picker. Swiping sideways on the slide control trips script triggers that update the dates shown to be that of the previous or next month. It's an illusion because the script updates a set of variables displayed on the center of three panels and then, after a brief pause so that the slide animation takes place, returns the focus to the center slide control panel. The first and third panels are actually blank. The illusion that you create is that you can endlessly swipe the tab control in either direction to get to different sets of values.
Where Tab and slide controls become handy in the context provided here is when you need a very different interface design for each panel of your slide or tab control. In that case, the need to put different combinations of fields,, buttons, value lists, etc may out-weigh the lack of flexibility.
Thanks for drawing my attention to the finer considerations of using portals.
No way I can say I'm on your level, but I tried brainstorming other ways to incorporate the onscreen elements. But I kept gravitating back to the multi-level tabs.
In my solution, the number of tabs for each level is pretty much fixed. I don't foresee this the number of tabs changing. And the number of panels on the embedded slider is definitely fixed.
There's a total of about ten designs. And the design for each is remarkably consistent. However, all the fields and buttons are completely different on each tab/slider.
Hope that explains my rationale.