Scripted Tabs and Portals

[macmukka]

I've been away for a while from FM and when I came back it had grown tabs - all in favour. With the techniques from the scripted tab example, they are almost there!

( 24 Scripted Tab Example Link )

I have three tables: quotes, drinks and tab names.

Records in the drinks table can have a type value of beer, wine, spirits, softs

I have a tabbed interface with the same tabs, beer, wine, spirits, softs taken from tab names table.

I am using the scripted tabbed interface example as my starting point and have this working well.

What I have tired to do is have a portal on each tab that displays drinks from the drinks db based on the field 'type' related to the current tab held in $$_active_tab. But I just cannot get it to work!

I have tried creating a new field which uses:-

GetNthRecord(Extend(drink_tab_names::Tab Name); $$_active_tab) in a relationship with drinks_type but to no avail!

This is my first post and I hope I have provided enough information.

Best - Jim

[Søren Dyhr]

So all in all do you wish to reverse the order of when buttons works vs. tabs - More trickery have shown up with fm8.5!

http://fmforums.com/forum/showtopic.php?tid/181251/post/225429/hl//

So the issue now is merely a layouting matter!

--sd

[macmukka]

Thanks SD

What I want is to show in a portal on each tab drinks (records) that correspond to the tab title, so when on wine tab, shows records in a portal with the type = "wine", on beer type="beer" etc

hope that helps!!

[ThatOneGuy]

Hi Jim and Welcome to the Forums!

FM has evolved a lot, and I think you're gonna enjoy working with it. For me, the biggest "bang" has been relationships. If you haven't had the chance, search the forums or FM's website for "white papers." Many happy returns will come from your investment.

What I want is to show in a portal on each tab drinks (records) that correspond to the tab title, so when on wine tab, shows records in a portal with the type = "wine", on beer type="beer" etc ... hope that helps!!

It helps a great deal, and it's pretty easy to implement. I thought it best to just include a sample file for you to inspect and dig around in. The crux is its use of "constants" on the parent side of relationships. For each type of drink, you need a constant to match up through the relationship. The individualized portals can be placed within separate Tab panels.

These constant fields are globals, so if you're modifying an existing system that's currently "served up," you'll need to take the files down, create and populate the globals, then fire it up again on the server ... so that the values in the global fields "stick."

There are two tables in the file: Quotes and Beverages. I created just two layouts and only the barest of minimums needed to illustrate the concepts. Take a look at the Table Occurrence Graph and how each of the relationships are defined. You'll also see how (1) sorting and (2) the allowance of record creation is applied to these filtering relationships.

Let me know whether it makes sense and if it's what you had in mind. :goodluck:

QuotesBeverages_01.fp7.zip

[macmukka]

Thanks for taking the time to put the example up.

I understand about relationships and I guess I could "hard wire" the globals. But I wanted to use the scripted tabs. like the link I have attached above, so that the relationship was drawn from what ever the active tab was.

So:-

A global field (equal to $$_active_tab) = drink_type

hope that makes sense!

[ThatOneGuy]

Hey Jim:

I understand about relationships

Sorry if my remarks imputed otherwise. I think I keyed in on your "this is my first post" sentence. Please accept my apology.

With respect to the substance of your topic, I must not yet appreciate the functionality you see in the plug-in's features. It seems that the "types" of drinks are "known," and it seems that the Tab panels' "labels" naturally correspond to those Types.

For the Active Tab to be determined (be it through global variables or fields), is this not established through some action by the user ... such as, but not limited to, clicking on a particular Tab panel, or a button, or changing the contents of a field? If this is true, then the static existence of filtered relationships would seem to provide the same result at the end of the day ... users click on the Tab panel they desire, and the related portal is displayed.

Alternatively, a global field could change the filter "Type" for the relationship, allowing a dynamic portal and perhaps obviating the need for Tab panels, altogether. Your last post mentions having a "global field (equal to $$_active_tab) = drink_type" ... couldn't just the global field drive the relationship in that instance?

I must be missing something. I'm not trying to be argumentative, and you don't have to defend to me what you're trying to accomplish, but I am curious about the functionality this will deliver in the long run.

[macmukka]

Didnt mean to extract an apology! ;-)

I think I must have been in the world of the web for too long where I try and save space eveywhere. It just struck me that as the scripted tab example has a string which at any time is equal to the number of the tab at the front. Then instead of hard wiring globals and having 4 extra fields, I could have one global that used $$_active_tab to grab the drink type from the tab names table, to then work in a relationship with the table containing the drinks.

Just trying to be semi-clever-ish. But I think for the sake of trying, I am going to hardwire.

Perhaps it doesnt work because the relationship is between two globals and not one of them is a constant. Although if i have a field which I have set up as a radio button I can do a conventional match using a portal. But if I convert this gloabl to a calculation that draws its value using the string $$_active_tab. It falls apart.

Perhaps something to do with calculating values.

Anyway off to put some hard wired globals in.

- also meant that if I only used the tab names defined in a table I didnt need to add more relationships if the database got larger.

Thanks for your help so far. All the best

[ThatOneGuy]

Hey Jim! Thanks for taking time to respond.

... I try and save space eveywhere.

That is a worthwhile objective.

Then instead of hard wiring globals and having 4 extra fields, I could have one global that used $$_active_tab to grab the drink type from the tab names table, to then work in a relationship with the table containing the drinks.

It seems the pursuit of efficiency in FileMaker sometimes delivers us into a "zero sum" result ... fewer fields in exchange for an additional table and each with its concomitant maintenance. (Not unusual in this instance for my brain to be caught in the endless Loop of its own Evaluate function. )

But if I convert this gloabl to a calculation that draws its value using the string $$_active_tab. It falls apart. Perhaps something to do with calculating values.

Yeah, if we end up with an Unstored value on the child-side of a relationship, that will cause problems. I don't know if that's your situation, but it has stymied me more than once.

also meant that if I only used the tab names defined in a table I didnt need to add more relationships if the database got larger.

Wouldn't that then dicate that you add Tab panels to the layout for the new constituents? Kinda makes me circle back to the "global filter" model....

Anyway, best of luck with your project, Jim, and I've enjoyed the exchange. Knock again if you like.

Respectfully.

[Søren Dyhr]

I have a grudge against globals, and saw this as a fine challenge, why litter a solution with global fields???

I twisted to reasoning quite a bit, the objective here is to avoid the oldfasion flipping thru layouts to mimic what isn't going on.

There might be alternative rendering of fonts on windows, but it only gives away the trick - so I hope windows users can see how to correct it.

--sd

test.zip

[ThatOneGuy]

Hi Søren:

Interesting approach in your example file. I liked your use of a single relationship.

I have a grudge against globals

They don't evoke any particular emotion in me. Filtered relationships can just as easily be driven by non-global, auto-enter, constant fields as far as I'm concerned. (In fact, there may be a few arguments in their favour.) In Jim's situation of course, this would require 4 fields to correspond to his current Beverage Types ... similar in regard to your example where 4 fields are used.

If field count is a concern, this exercise still seems to lead back to a "dynamic, filtered relationship" model. One could place concealed buttons over Tab thumbs and achieve about the same result, again with just one relationship. The button's step/script would set the filter field. And as you know, it would have to be a global field if the solution is intended for simultaneous, multiple users.*

Notwithstanding all my rubbish, I respect your efforts and expertise. It usually makes me take a different perspective on a problem.

* There's no "law" against it, but if the filter field is non-global, User A could change the relationship's filter during User B's session, and vice-versa ... what a mess!

[Søren Dyhr]

, it would have to be a global field if the solution is intended for simultaneous, multiple users.

You might re-poke into the Kazar woman's part in the Migrationfoundations whitepaper concerning record locking, which have been totally refurbished from fm7+, you might have this old recordlocking from fm6 where only one user could see the same record at a time, but now is record first "open" when a user enters a field an changes something!!!

I have thought my template into a similar utilization as Shawn Flisakowski's template:

http://www.spf-15.com/fmExamples/datePickWindow.fp7.sit

Where you just attend a clickable, here pick the recordID and stuff it in a $$variable, that could be part of an autoenter value in a record creation. But never ever enters into a field!

I'm saying this because I never have heard any recordlocking issues with GetNthRecord ...although I at present can't test if my understanding is correct. But the whitepaper seems to convey this meaning??

--sd

[Inky Phil]

You might re-poke into the Kazar woman's part

Steady on Soren. There may be children around!

Phil :)

[bradford]

Wow, this is perfect. I am having a similar issue with what folks here are calling "filtered portals." Studying the emails above I am now wondering if I am on the right track, after all.

My solution is similar enough to stick with "beverages." What I tried to do was put one portal on one tab, and one portal on another tab, both the same table. One showed all, and the other showed the limited, selected bunch (let's say "wines").

I hit a glitch when I change the info on one portal, it doesn't change it in the other. Super confusing.

I'll see if I can take a screen grab.

[ThatOneGuy]

Hi Brad:

I hit a glitch when I change the info on one portal, it doesn't change it in the other. Super confusing.

This whole "filtered portals" technique is pretty powerful, but it does have its share of "moving parts." I often must double-check that I have the proper fields of each relationship in the proper portal.

Keep us posted on what you find, and I look forward to a screenshot or sample file. :cofeebrake:

[Søren Dyhr]

I hit a glitch when I change the info on one portal, it doesn't change it in the other. Super confusing.

If it's my template you refer to is it obvious why a portalized object can't be in more than one, because of the primary is the same field as the foreign, for that do you instead have to make the primarykey for the relation that can have either the distinctive or a multilinekey by calculation, often can it be done by ValulistItems( or the new List( function.

Do you need a new template??

--sd

[bradford]

Well that's good news to hear, that this stuff is in fact "tricky." I've been working with FM for years and constantly reminded to remain humble. ; )

So I took some screen shots. Not sure if that's the best way to do this. Let me know. The database is huge so sending even a clone would take a long time.

The solutions isn't "beverages," it's people—invites, RSVPs. I am hoping to show who was invited on one tab, and who RSVP'ed on the next.

Somewhere along the way I think the Global value isn't holding because as soon as someone gets invited to one event, then removed, they then get removed from other events they were to attend. It's like the relationship is leaking.

Please do let me know what you think.

Plan B is to create some sort of filter portal from scratch.

Brad

comcomcom.zip

[Søren Dyhr]

Ok, I've toyed with your problem, and have indeed seen by this example, how much better features the newer versions provide, anyway here's my stab at it with the tools availiable with fm7. It took a great deal longer to develop, than expected.

I have made some regrettable choises in the choose statements that clutters the readability of the scripting and calc'fields I appologise for not correcting them once and for all.

But as such is it what I call the Jeff Almquist method (he made an article in Advisor several years ago on this technique) which is utilization of multiline keys to make the sets the portalkey depend on as well as the markings in the portals.

It's only the last part originating from Jeff's approach the other should be common knowledge in how to avoid the join table in many-2-many relations.

I have in this template tightned the mergefield bit slightly, using that you can colour sections of your text in various colours, so only two fields is required, where the one having white into it - is used to 3D a bit.

Again could the rendering be slightly misleading and you should adjust accordingly if the things looks ugly on windows, bu getting the right combination of fontsize and the number the _ is repeated in the calc ...well it's easier to change the buttons size it should overwrite.

I have chosen a bygone way of layouting, only because it's the fastest way for me to give this example, the technique could easily be filled in a more contemporary dito.

Finally couldn't it be stessed enough that buttons in my layout are the ones to use and not shortcut-keys or the measures provided in the status-area, this is often debated by developers and with fm8adv do you have a way to overwrite those with your own shourtcuts, prior to this was plugins employed to provide this scripted behaviour ...that here are so urgents to keep.

--sd

tripplecom.zip