Sounds like you are trying to create something in FileMaker 12 for which we'd use a PopOver for in FileMaker 13.
Interesting. I had to experiment with a layout to understand what you are describing. What you are reporting is something that is "the nature of the beast" as far as I can tell.
Do you want the fields behind to be visible but not accessible or do you want them to not be visible?
If you never want them to be accessible but still visible, you can use the Inspector's behavior settings to deny Browse Mode access to the field.
If they should not be visible, I'd add one more panel to your tab control and put them inside the tab control.
If they are to be visible and accessible under certain circumstances, you'll need to explain those circumstances.
To answer your question:
"Do you want the fields behind to be visible but not accessible or do you want them to not be visible?"
The fields behind should not be visible when the user is on tab 2 and tab 3, because we are mimicking a pop-up window.
"If they should not be visible, I'd add one more panel to your tab control and put them inside the tab control."
I think I'll move all the fields on the background form onto the blank tab so the fields aren't accessible when the user is on tab 2 or 3.
Yes, but when I tested this, the fields in the background were only visible if the transparent panel was in front. It's only then that you have visible and accessible background fields and I would expect that you'd want them to be at least visible at that time. Otherwise, I don't understand why you would set up a panel to be transparent in the first place.
It's exactly that.
- Background layout has fields.
- Tab control that is smaller than the layout and sits on top of the background has 3 tabs: 1st tab is blank, so the fields on the background are visible.
- Blank tab is the default tab and therefore always shows all the fields on the background when you first open up this layout.
- When user modifies a field, the script trigger performs some action and goes to tab2. At this point none of the fields on the background should be visible nor accessible.
So to get around the problem, I am taking your advice and putting all the fields on the background layout into the blank tab, so they are not visible or accessible when the user is on tab 2 or 3.
When user modifies a field, the script trigger performs some action and goes to tab2. At this point none of the fields on the background should be visible nor accessible.
Is tab 2 also transparent? It would seem simpler to give tab two an opaque fill color and then the fields in the background will not be visible when tab 2 is the front tab panel.
I'd post the file but trade agreement prevents me to share any of the screenshots.
Other than the blank tab, no other tab is transparent. Otherwise it beats the purpose. It'd be all garbled up on top of each other. And although tab 2 and 3 are opaque or in this case covered with another graphic, the fields in the background are accessible.
I'll try to explain. I'm creating a simulator that mimics browser behaviour when a user is entering some information.
- Layout is a registration form. On this form, there is one field. User types something into that field. On exit it pops up another window so the user can input some other information into new fields.
- In order to mimic that, I inserted a tab control with 3 tabs. First one is transparent so the user can enter information. Second and third are not transparent. It's simply an image of another form with fields placed on top.
- However when the user is on tab 2, although not visible initially if you click around on the second tab, your cursor goes into the fields that sits on the background.
- Your solution of moving all the fields in the background layout to another tab, in this case blank tab, worked. This way, those fields that were i the background are no longer accessible or visible on other tabs.
Hmm, "clicking around" doesn't allow me to enter that field when I test it--I get a brief "flash" of the field borders but control remains in the tab panel and the field does not appear, but I can use the keyboard to enter the field by pressing tab, return or enter (The key that does this depends on field behavior settings).
That does clarify things as the field is not visible with the opaque tab panel in front. But it's the fact that the user can still enter the field when it's hidden behind the tab control that's the issue.
I guess I'm using tabs in a non-traditional way. The users can't click on the tab headings to go to any of the tabs. I've set the width of the tabs to 0. So it doesn't even show. No lines around the tabs either. So on the default blank tab, you wouldn't know that the tab is even in there...
Zero width tab labels are pretty commonly used trick and what I assumed was the case here from what you have posted, but I don't see how that affects the issue at hand. Either way, when the opaque panel is in front, I can only get to a field behind the tab control by a "go to next field" action--such as pressing tab or performing a script with such a step.
I can't reproduce this with just a mouse click.
Cross-posted, it seems.
The clicking around does get into the fields on this layout. That's why I wondered if I should select the whole tab control and go to Arrange > Bring to Front, in case the fields in the background were somehow brought to front.
I've created lots of other layouts with invisible tab controls to do exactly that. This one for some reason is not behaving like the ones before. I deleted it, recreated it.. still the same.