Is there a way to have different layouts from other tables in each tab of a tabbed layout?

[foobaz]

I am working on a relatively complex relational database that logically has different tables for each category of data. I want the user interface to be intuitive and simple so tabbed panels seem like the obvious choice. A tree structure would also be OK but that solution is not built into FMP 8.5. I set up a preliminary tabbed layout with more tabbed panels inside of each outer tabbed panel. I discovered, much to my horror, that I cannot add fields from other tables than the one associated with the tabbed layout and have them accessible in Browse mode. The fields are inaccessible and say "

There must be someone here who has done exactly what I am trying to do. Thanks for all help.

[Søren Dyhr]

I discovered, much to my horror, that I cannot add fields from other tables than the one associated with the tabbed layout and have them accessible in Browse mode. The fields are inaccessible and say "

But relations exists between the table you have stuffed in the tabbed layout, and the other tables, if not do you need to glue on TO's according to your needs. What might confuse you is that the RG isn't a ERD ...have spend some time studying this document??

http://www.digfm.org/ref/FM7_key_concepts.pdf

Layout as you please, but you need attach enough TO's to the part of the RG the particular layout uses, to usher in the fields.

--sd

[Tim W]

Hi,

If your tables do not have a natural relationship "=", you can use the "X" relational operator. This connects the tables and makes for what it sounds like you are looking for (an unequal join).

IMHO,

Tim

[Ender]

Is there some way to have other layouts appear in a tabbed panel?

No. A tab panel is an element of a layout, not the other way around.

To provide tab navigation among different layouts, use buttons that look like tabs.

[foobaz]

Thanks for the reference but I will have to study this to understand exactly what you mean.

But relations exists between the table you have stuffed in the tabbed layout, and the other tables, if not do you need to glue on TO's according to your needs. What might confuse you is that the RG isn't a ERD ...have spend some time studying this document??

http://www.digfm.org/ref/FM7_key_concepts.pdf

Layout as you please, but you need attach enough TO's to the part of the RG the particular layout uses, to usher in the fields.

--sd

[foobaz]

How would you do this and be able to create new records in the connected table from the other table's layout? So far I am only able to create new records for the outer table that the layout is associated with and not the connected table.

Hi,

If your tables do not have a natural relationship "=", you can use the "X" relational operator. This connects the tables and makes for what it sounds like you are looking for (an unequal join).

IMHO,

Tim

[foobaz]

Yes you could do it that way but that's the last way you really want to do it. I started out doing this but soon learned that it is really tedious and time-consuming to modify any layout. You have to modify all the other layouts with the change. The Smart Tabs approach is certainly much better and much easier to maintain but it is still not a "native" solution to the problem.

No. A tab panel is an element of a layout, not the other way around.

To provide tab navigation among different layouts, use buttons that look like tabs.

[Ender]

It is what it is. One way is easy to set up but harder to make changes to, the other is hard to set up but fairly easy to make changes to. What's "better" may be in the eye of the developer. Having tried different calculated button techniques, I prefer to keep tabs as simple, non-calculated graphics. I don't find the tab sets changing often enough to warrant adding calculation overhead or dealing with dubugging them.

However, I do agree that it would be useful to have a way to have some elements shared across multiple layouts. My thought is to actually have a layout Part that's defined to be used for a group of layouts. Maybe in the next version, eh?

[foobaz]

OK, by better I meant that the scripted approach is certainly more elegant from a programmer's point of view and is easier to maintain while the other method is brute force and difficult to maintain. The work has already been done for smart tabs so you could leverage off of that. I would not attempt to use that approach if someone hadn't gone through the trouble of setting it up and debugging it. Smart tabs do allow different layouts in every tab panel however they all still must come from the same table. I want to access different tables as well. And I have yet to successfully create nested tabs with it. It is very difficult to change the scripts associated with each tab which is at the heart of the ability to go to different layouts. You must ungroup the invisible buttons which are under two other groups of buttons. Then you have to make them visible so you can work with them and change their associated script reference. I can't make them invisible again with FMP 8.5. The 'none' option is gone for the fill and pen color. So in the end this is no easier and I am stuck with the brute force method unless some guru can tell me a better way. Is this as good as it gets? I guess I was expecting more from a mature product that has been so heavily hyped in so many places on the web...

As for implementation details, I can envision a container object that can contain layouts from any table, or at least a header with global scope where you could place all the tabs and subtabs.

It is what it is. One way is easy to set up but harder to make changes to, the other is hard to set up but fairly easy to make changes to. What's "better" may be in the eye of the developer. Having tried different calculated button techniques, I prefer to keep tabs as simple, non-calculated graphics. I don't find the tab sets changing often enough to warrant adding calculation overhead or dealing with dubugging them.

However, I do agree that it would be useful to have a way to have some elements shared across multiple layouts. My thought is to actually have a layout Part that's defined to be used for a group of layouts. Maybe in the next version, eh?

[Tim W]

Hi,

How would you do this and be able to create new records in the connected table from the other table's layout?

Scripting of course. Freeze the window, go to layout based on the object TO, new record/request, and set foreign key(if needed), then return to orginal layout & refresh. The user will not see the process and the trick will give the appearance of just adding a new record right there in the tab.

HTH,

Tim