Scripted Tab Panel Navigation - buttons don't work within tabs?

[davidnickerson]

I'm trying to simply script tab navigation using the commonly-recommended method of naming the tabs as objects, and the using a GoToObject script step.

 

While this certainly works with script buttons placed outside each tab on the tab panel, it doesn't seem to work when placing buttons on the tabs themselves.

 

I.E., I have button on tab 2.  It's displayed properly from Tab 1, but when attempt to click on it (from Tab 1) I'm navigated to Tab 2 first.  Only then can I actually click on Tab 2's button.

 

If this is standard operating procedure for Tab Panels, then scripted navigation is useless, imo.  I mean, I'm scripting the navigation to OVERRIDE the existing tab navigation in the first place!

 

Am I missing something here?

 

Thanks in advance for any assistance with this.

[David Jondreau]

If you have a button on tab 2 how can you see it from tab 1?

[davidnickerson]

If you have a button on tab 2 how can you see it from tab 1?

Not sure what else to call the "tabbed" portion (where the "text label" resides) that's visible from all tabs.

 

A "Tab Control" is FileMaker's term for the group of tabs.  What term would you use for the portion of the tab that's visible from other tabs?  In any event, it would seem natural to be able to place a button in this portion so as to override the default behavior of navigating to that tab when it's clicked.  But, apparently, I can't do that.

 

When FileMaker details the process for "How to Navigate Between Tab Controls Using Scripts" ( http://help.filemaker.com/app/answers/detail/a_id/6145/~/how-to-navigate-between-tab-controls-using-scripts ) they simply say "Add a Button to the Tab Control".    Again, adding a button to the top "tabbed" portion renders the button useless from other tabs.

 

Am I going about this the wrong way?

 

What I need is to be able to create conditions for tab access.  If the condition is met for a particular tab, the user can click on that tab (say, Tab 2) and will be taken to that tab.  If the condition is not met, clicking on that tab will do nothing.

 

Make sense?

 

Thanks again.

[bruceR]

No, this does not make sense.

 

The selector portion of the tab IS the button. Nothing else belongs up there.

 

There is a functioning example file posted at the link you posted.

[davidnickerson]

No, this does not make sense.

The selector portion of the tab IS the button. Nothing else belongs up there.

There is a functioning example file posted at the link you posted.

 

Sorry this doesn't make sense to you, but you're describing the issue perfectly.  "The selector portion IS the button.  Nothing else belongs up there."  In other words, you can't have conditional tab navigation using the existing "selectors"; you must create an additional button OUTSIDE the selector, which is COMPLETELY NON-INTUITIVE to a user.  The functioning example you mention illustrates this.  They have an additional button on Tab A that reads, "go to Tab B" while there is still the "selector" for Tab B sitting right there, waiting to be clicked.

 

FileMaker offers so much flexibility in so many other areas, it's surprising that Tab Controls are still so restrictive.

[David Jondreau]

Well, it's not intuitive to you, but perhaps it is intuitive to other users. Regardless, you can't do what you want to do the way you're trying to do it.

 

But there are several other solutions. You can eliminate the tab portion entirely by setting the width to 0 and removing borders and replicating them as buttons.

 

But I think you'll find best success with the OnTabSwitch trigger and the Get ( TriggerCurrentPanel ) and Get ( TriggerTargetPanel ) functions to control navigation.

[bruceR]

DavidN: your explanations are unclear.

 

You still have not provided an example file that illustrates what you want to do.

 

It should be obvious that the example file merely shows an extremely simple example of how buttons can control named-object navigation. It is not relevant in this simple example that the tabs are visible and selectable.

 

There are ways to completely hide the named tabs so that only buttons allow actual tab switching.

 

But - once again: nobody knows what you want. You will get further by providing an example.

[davidnickerson]

Well, it's not intuitive to you, but perhaps it is intuitive to other users. 

 My client thinks it's non-intuitive; he's the only user that matters.  Honestly, though, I always find redundancy to be less than elegant.  If you have a button that reads "Tab B" near a tab 'selector' that reads "Tab B", and they both navigate to Tab B...well, if I have to explain this again... 

 

 

But I think you'll find best success with the OnTabSwitch trigger and the Get ( TriggerCurrentPanel ) and Get ( TriggerTargetPanel ) functions to control navigation.

My client's company has not made the switch to FM 12 at this point...may take a while for that.

 

You can eliminate the tab portion entirely by setting the width to 0 and removing borders and replicating them as buttons.

True, but the amount of work involved to accurately re-create the "tabbed" look and feel-- raised front tab, conditional color changes, etc.-- is a bit much in addition to the conditional scripting needed for each tab.  Thanks for the suggestion, though.

 

 

 

 

Regardless, you can't do what you want to do the way you're trying to do it.

Exactly.  

[davidnickerson]

DavidN: your explanations are unclear.

 

You still have not provided an example file that illustrates what you want to do.

 

Sorry about that.  However, I don't think an example file would help.  Since I can't design what I'm looking for in the example file, I would be left explaining things about the example file, such as "I want to place a button on the Tab B selector, so that I can control tab navigation with a script."  I have already said as much, and it has been unclear.  I don't think a non-working example file would make it more clear.

 

In any event, your responses have indicated (to me, at least), that you understood what I was looking for well enough to tell me that it couldn't be done.  Which is fine, by the way.  I do appreciate you trying to help.  Thanks.

[bruceR]

What you are saying is: "I don't know how to do X. I will not explain X. Therefore FileMaker cannot do X."

 

Your conclusion is not valid.

 

Yes, YOU cannot currently do X; but X is undefined.

 

If you cannot explain where you're trying to go you can't get there. 

 

You CAN create an example file that illustrates what you want to accomplish without actually accomplishing it. You can say, when I click on object X I want this to happen.

[davidnickerson]

What you are saying is: "I don't know how to do X. I will not explain X. Therefore FileMaker cannot do X."

Are you trying to be mean?

 

It's fine if you don't understand me, or if my explanation does not meet your expectations.  But pretending that I'm not offering an explanation is disingenuous.

[bruceR]

No, I'm not trying to be mean. I am not saying that you have not offered explanations; I am saying they are unclear and incomplete and you have opportunities to clarify and perhaps even solve the problem you are trying to solve.

 

You have been offered solutions that meet what can be understood from your explanations; you have rejected them.

[davidnickerson]

Bruce, I'm really not sure what you're fishing for.

 

Here's what I'm trying to do:

 

"place a button on the tab selector, so that I can control tab navigation with a script."

 

I'm using your word, "selector", so there's no confusion there.  You have stated, "The selector portion of the tab IS the button. Nothing else belongs up there."  Mr. Jondreau has also suggested that this is not doable.  I understand this, and I've stated that.

 

I've also stated that I cannot use FM 12's tab triggers for this solution.

 

I've also stated that spending the time necessary to re-create the entire 'tab portion', as Mr. Jondreau describes, or 'selector', as you term it, so that it replicates the look and feel of FM's existing Tab Control is probably more $ than my client wants to spend.

 

Are these the 'rejected' alternatives to which you refer?  Is it not acceptable to reject a solution if I don't find it adequate?

 

Another solution would be to simply create separate tab-style layouts to handle the conditional navigation.  And I've considered this as well.

 

For the record, I'm OK with not finding an adequate solution.

 

An adequate solution would be to be able to place a button on the selector, or otherwise change the clicking of a selector so that it calls a script.

[bruceR]

No, I'm sorry but it still is not at all clear. That's why I keep asking for an example.

 

Why place a button there when there is already a tab selector?

What different thing is supposed to happen when you click on the tab (button)?

What is supposed to be different about the appearance?

 

Note that there existing example files that show how to create zero-width tabs. Therefore the buttons are the only thing you can actually click on to cause navigation.

Example in next message.

[bruceR]

Example. Compare the different layouts, where the standard tab controls are full size, then tiny, then invisible.

 

It illustrates that the tab controls can be made invisible and unselectable to the user, and therefore you can design other controls to do the navigation, strictly by script, with the appearance of the controls whatever you want.

TabExample.fp7.zip

[davidnickerson]

Why place a button there when there is already a tab selector?

To create a condition for tab navigation, as mentioned in the very first post, and repeated ad nauseum.  Is there a way to do this without placing a button there?

What different thing is supposed to happen when you click on the tab (button)?

Instead of immediately navigating to, say, Tab 2, a script would be called.  The script would, for example, check to see whether a field had a certain value.  If the value was "2", the user would be navigated to Tab 2.  If the value was 1, there would be nothing to see on Tab 2, so the user would not need to go there.  The script would exit and no navigation would take place.

What is supposed to be different about the appearance?

Not sure what you mean by this.  There should be nothing different about the appearance of the tabs, nor did I request that there be.

Note that there existing example files that show how to create zero-width tabs. Therefore the buttons are the only thing you can actually click on to cause navigation.

Example in next message.

Duly noted.  And understood beforehand.  And discussed (or 'rejected') earlier.

 

I appreciate you taking the time to create and send the example file.  But I'm not sure why you're doing this.  It really just seems to me that you're trying to get me to chase my tail or something.  I'm not interested in playing a game with you.

 

I feel like I've answered your questions, over and over, and you keep saying, "no, that's not quite it.  try harder."

 

So let's turn this around:  Your example file does not illustrate how to re-create the exact look and feel of FileMaker's tab controls by using zero-width tabs, conditional scripts and buttons.  Please re-submit the example file.

[bruceR]

Sorry, I give up. I have no idea what you want. You want something that looks exactly like a tab panel; does not have an appearance that is different than a tab panel; but for some reason a native tab panel is not sufficient. I really have no idea what you want.

TabExample.fp7.zip

[davidnickerson]

 You want something that looks exactly like a tab panel; does not have an appearance that is different than a tab panel; but for some reason a native tab panel is not sufficient. I really have no idea what you want.

Why do you keep pretending not to hear what I've said? 

 

I've repeatedly-- REPEATEDLY-- described the type of conditional scripting I'm interested in.  And yet you completely leave that out of the above statement.  If you were really being honest, and not insincere with your attempts to help, you wouldn't keep leaving out things I've said, or attributing things to me that weren't said.

 

I really don't believe you're a troll.  But why are you being disingenuous here?

 

Throughout this thread I've made attempts over and over again to explain what I want.  If you weren't being disingenuous you would not respond with statements like, "you will not explain X".  You would instead simply state what part you don't understand and perhaps say, "do you mean this?"

 

I've repeatedly stated that I'm looking for a way to have a button on the top portion of the tab that navigates to other tabs (the "selector" as you call it), so that I can have a scripted condition that determines navigation.  I've given an example of this conditional script as well.

 

In the beginning of the thread you mention that "The selector portion of the tab IS the button. Nothing else belongs up there."  And I've acknowledged that.  But yet later on you act as though I'm not asking for that ( "You want something that looks exactly like a tab panel; does not have an appearance that is different than a tab panel; but for some reason a native tab panel is not sufficient." ).  If you weren't being disingenuous you wouldn't do things like this.

 

Also, I have not been able to view your latest example file.  I get an error ("you do not have permission to view the attachment").

[bruceR]

The download works now.

No, I don't ignore the statement.

I tell you it is ambiguous and ask you to draw a picture.

Continuing to proclaim that what you have in mind is clear to you therefore it cannot be ambiguous to anybody else just doesn't work.

Draw a picture.

DavidJ pointed out how buttons behave across tab controls.