to tab or fake it?

[agtjazz]

Hi

I have been reading tons on this site and others as well... and can't seem to find "the answer". So I am going to post my question (and it may appear a no-brainer to some)... but I would truly appreciate some clear direction.

Tabs-- I have multi tables and would like to create 1 layout for data entry for a person. I have tab 1 for personal info (off the people table) and tab 2 is for Job info (off the job table) and tab 3 is for Appt (off the contract table)... Job and contracts are related to people table.

So do I do tabs? or fake tabs?

Your recommendations will be greatly appreciated!

[comment]

I believe this thread might help you decide.

[Ender]

In my opinion, the Tab Panels are okay for simple interfaces to take a layout with a lot of fields and break it down into easier to swallow pieces, but I don't think they're appropriate in more complex solutions as the navigation control and appearance are still rather clunky.

And of course, for the reasons detailed by comment in the other thread, they are not appropriate for trying to tab to different TOs.

So I guess my vote is "fake tabs." :D

[LaRetta]

And don't forget that tabs are also great with portals. How many times have we wanted to stack two portals in the same space? Now we can. I've been using tabs to hold the 'lists' of related records or activities (like indexes) and a GTRR click-jump to the detail (on another layout). They may be just a layering device but it sure cuts down on the number of layouts and duplicate layouts containing portals ...

Neither do I think they're clunky looking - if set embossed 1 pt. (transparent pen) in an elegant muted color, they add finish to the layout and draw the eye appropriately.

:wink2:

[Søren Dyhr]

the navigation control and appearance are still rather clunky

I agree here, a tightning of the code is required ...at present is it a pretty fat cat to swing. Laretta it's not the looks that worries as much as the time it takes rendering scripted matters like this:

Freeze

Go To Field[fractionedRepeat[3]]

Go To Field[]

Which is the present method for swithing between the tabs by script!

On the other hand is there task where latencies are expected such as portals sorting. The way this template uses tabbed layouts behaviours is interesting:

http://www.filemakerpros.com/LessSort.zip

Because it's faster to implement than the ususal with buttons attached to scripts.

--sd

[Søren Dyhr]

Now the next question is how you fake it?? Say you have an identically sized and related portal under each tab ...only thing you fiddle with is the key values for what should be shown.

I touched in my previous post in this thread, that I found the rendering somewhat lacking to be desired. Since in this case there hardly are use for versatile objects location, isn't a genuine tabbed interface required.

But how drastic would you approach it?? Would you make screendump of a genuine one and whirl each selection thru graphic converter to trim to upper left corner as well as getting rid of the text to prevent jagginess. Put real fields ontop ...or do you have some nifty tricks up your sleves??

--sd

[LaRetta]

Well, ummm, I think I would use Repetitions.

I could NOT resist the opportunity ... :smile2:

[Fitch]

Tabs are most appropriate when you have one part of a layout that doesn't change, e.g. the contact info; and then you put the changeable part on the tabs.

Tabs save you a LOT of time creating and -- let's not forget -- maintaining your layouts.

So agtjazz, I see no reason why you couldn't or shouldn't use tabs for the scenario you described.

The downside of tab objects is that the tabs cannot act as buttons. There are workarounds, but they are cumbersome. So if you need to run a script as part of the navigation, use fake tabs.

[agtjazz]

Maybe it's because I haven't had my coffee yet, but I thought that I have read (from Comment's and others' posts) since I am using relational tables, that I can't use tabs.

I have a table called People, which basically contains personal info (ie address, phone etc)... a table called Jobs, which basically holds peripheral employment info (ie account number, position title, date of hire etc).... a table called Contracts, which holds salary and teaching units, etc. (relationship is people>jobs-one to one and people>contracts- one to many)

For data entry, I was trying to see if tabs would work, so a new employee could be entered quickly in a tabbed data entry layout- but the user would have to hit at least the 3 of these tables as mentioned above (if not other tables in addition to those).

I was leaning toward faking it... but am starting to get confused again. :qwery:

[LaRetta]

Then fake it. Because, as mentioned, Tab Controls can NOT apply to different table occurrences.

BUT ... if you can live with viewing and working in your related data via portal, it would work. But for providing views of ALL your different table occurrences then no, because you'll want list views and form views (and if one-to-many only the first related would show if you placed the related field directly within a tab). Your entire solution can't run under tabs. So you might as well do what we all do ... fake the tabs for moving between table occurrences and use tabs for jumps between the same table occurrence (excluding list view).

[agtjazz]

LaRetta,

Can I ask an obtuse question?

Well, ummm, I think I would use Repetitions. ..............

Can you give me an overview (or a link) on how you would use the Repetitions?

Thanks bunches

[Søren Dyhr]

Well here's one:

http://www.onegasoft.com/tools/smarttabs/index.shtml

here's another one!

http://www.filemakermagazine.com/modules.php?op=modload&name=News&file=article&sid=555&mode=thread&order=0&thold=0

--sd

Edited April 11, 2006 by Guest
Came to think of another one!

[Fitch]

Anything you can put on a layout, you can put in a tab. This includes related fields, whether or not they are in a portal.

Since you have some interest in the idea of a tabbed interface, why don't you just build the layout with a tab object. If it doesn't suit your needs, then build a new layout instead. You'll have learned something and no baby seals will have been harmed.

[coconutt2000]

For what you've describe, use the tab control layout item. Anything you can do with fake tabs you can pretty much do with the new tab system.

Just remember to allow the creation of new records in the related table, otherwise you won't be able to enter any data into the fields. The newly created records will automatically inherit the related key from the parent table, locking the new related record to the parent record.