Conditional layouts

[bradford]

Is there such a thing as conditional layouts?

I'm using FM7. I am working with two databases: television projects and film projects. I would love to be able to combine these two into one as they are each considered "projects" outside the database (and 80% of the fields are same).

I am envisioning a list layout with both type of projects listed. Click on one and it takes you to a card layout, let's say television show project. Next card though, as it is say, a film project, will need to show that 20% different information (different fields need to "appear" on the layout.

Make sense?

[PeterHW]

There are several ways to do this, but making two different layouts for both categories would be the easiest. Your navigation should then be scripted. You would need one field that could divide film projects from television projects (for instance ProjectType) and switch to one of the layouts based on the contents of the field.

So in your list view, the field you click on should be defined as a button, with a "Perform Script" action attached. The script could be something like

If [ProjectType="Film"]

  GoToLayout [FilmDetails]

Else

  GoToLayout [TVDetails]

End If

Regards,

Peter

[SlimJim]

You could also by suitable naming of the layouts use a goto layout name by calculation:

GotoLayout(ProjectType)

[Crankopotamus]

This is exactly what I am dealing with in my hardware database. Using your example, I have a "projects" table with two related sub-tables containing only the unique fields, "Film_project_specs" and "Television_project_specs." Then I put a portal for each subtable on my layout. One is empty (no related records) and the other shows the related specs.

Now I'm trying to figure out how I can use transparency to layer one portal on top of the other, in order to take up less room on the layout. If the top one doesn't find any related records, it would let the bottom one show through. This may either be simple or impossible, but I've just started using FMP 7 so I don't know. Any suggestions?

[SlimJim]

I don't think transparency of portals is available in the sense that you have mentioned. You stated that your project spec tables have a unique field ..specs and that only one of these is relevant to a project record. This might be a case where you simply copy the data into a field. Specs = filmrelated::Filmspecs & TVrelated;;TVspecs and then show this on your layout. If you make it into an unstored calculation it will not use up a lot of file space.

[Crankopotamus]

I knew I'd get into trouble using the original example. Sorry. It's not just one unique field per subset table. My main table is a list of computer hardware. There are several fields that describe CPU specifications, such as processor_type and clock_speed, which have no value if the item in question is a monitor. Therefore I have put these fields into subset tables. If I'm looking at the record for a monitor, the CPU_specs portal is empty.

I think it would be more trouble than it's worth to do multiple layouts. I'm thinking of printing in particular...I don't want to have to write a script to switch layouts on the fly while generating a print job. Is that the way it's typically done?

If I can't overlap portals to save screen real estate, so be it. Thanks for your thoughts.

[Vaughan]

"I think it would be more trouble than it's worth to do multiple layouts. I'm thinking of printing in particular...I don't want to have to write a script to switch layouts on the fly while generating a print job. Is that the way it's typically done?"

Yep, it sure is.

Everything gets scripted. Everything gets controlled. Everything gets predictable.

This is one of the differences between an amateur job and a pro job. (No offence intended, but I am often involved with converting in-house designs to something that work reliably.)

The other main difference is error checking in scripts. And field validation. And decent security.

[Crankopotamus]

No offense taken. I am definitely an amateur. That's why I'm here, asking questions: to learn the best way to do it. Thanks!

And: woo, that's a lot of scripting. I figure I have to replace a lot of the built-in functionality of the U/I, like the next/previous record flipbook. My project just got a whole lot more complicated. But it'll be worth it in the long run.