Multiple Portals on layout causing issues...

[agutleben]

Okay, here is the issue:

I have a solution that consists of many tables. I use a primary table to display the related tables data in about 5 portals on one layout. The affect I am trying to achieve is the ability to show a path that someone may take when selecting something in each of the portals. (See the attached screenshot)

Ex: The portals are: Business / Location / User / etc...

When you select a business, you see the related locations. When you click on locations, you see the related users and so on. The portals all work correctly at this point. Here is the tricky part.

I am implementing a highlighting feature that shows the path between the portals. When you select business A, then business A becomes highlighted, and you see business A locations show in the locations portal. When you select business B, business A looses its highlight feature, and business B gets highlighted. This is done by using the Replace script step to clear all my highlighting fields. This works perfectly in portal 1 (Business portal). In portal 2 (Locations), I can get the correct fields to highlight (I use set field), but if I use the replace to clear my fields, I loose the ability to correctly set my highlight fields, and it reverts to the 1st record in the portal. I have tried trapping the current portal row and storing in a global which I recall a little later in the script, and the trap works, but again, it will not resolve correctly at the scripts end. I know this is not explained easily, but does anyone have any experience with multiple portals on a layout, and trapping the correct related record in a fashion similar to the above example. Many thanks...

[cellmaker]

Agutleben -

I have done something similar to this, and I've found that the best way of "highlighting" where you are in a portal is to use a container field that is switched on by calculation. So in effect, if you have chosen a certain "row" (record) in a portal, set a global that matches whatever id you have for that record. Your calculated container field then activates (i.e., if gl_id=id, container = something, else nothing). The container field is put behind your text field in the portal and will therefore become "highlighted." This can be done for any table, so multiple portals on one layout shouldn't present a problem.

The one thing that is difficult (I think) is to show these records in portals that have more records than portal space. If they are in the usually-viewable area (i.e., within the first x rows that you show), then no problem. If they are further down on a scrollable portal, though, focus is difficult to maintain because portals aren't very "sticky."

Hope that makes sense.

[agutleben]

That is a great idea... and one I did not even consider. I did do a little research on portal functionality and the changes in 7. The portal is supposed to leave you where you last were in the portal when you exit it, unlike previous versions which would reset the portal to the first record based upon your sort. I have not tested this yet, but that is what the documentation says. Thank you for the idea!

[cellmaker]

One other thing. It's not very elegant, but one way of resolving the sticky portal issue is to sort a portal based on the highlight and then the normal sort order. You could, in effect, bring whatever you were highlighting to the top of the portal.

This might not be very attractive and it might be distracting to the user to have records moving around in the portals.

Just a thought.

[agutleben]

This was a great idea and works fabulously.. This method also removed a lot of overhead, and made for a much smoother experience.

[color:"red"] A note to others who may read this: Make sure to evaluate the calculations based on the correct relationships to which they apply.

Thank you for the advice!

[John Glenn]

in an example of convergent evolution, I had the same problem and came up with the same solution as you all. But I discovered a big bug: if the user uses the new FileMaker 7 "New window" command, and views a different customer in the new window, you can't use a single global variable to track the active row for the portal, because both windows then jump around together. (In my database, the portals show different information for different customers in the DB.)

I got around this by creating a table with the current user ID, record ID, and active item ID for each portal. Everything is connected with relationships, but it was a bit of a nightmare untangling the spaghetti. (the user ID is needed to prevent one user's selection from showing up in another user's window)

One big problem I haven't found a good way to solve is that FileMaker doesn't seem to properly update portals that are related to the current layout by several relationships chained together. I have to manually refresh the window by going to the next record and back to the previous record. This is kludgy, and also causes the portals to snap, lose their stickiness. I'm about to try saving the portal row in a variable and going back to that portal row after refreshing, but this is all gross, there must be an easier way of refreshing the window to correctly display portals.

Any ideas?

[John Glenn]

P.S. Go to Portal Row is not an ideal solution for fixing stickiness, because it leaves the selected row at the very bottom of the portal, which isn't where it was a moment ago when the user clicked on it.

So the user selects an item in the middle of the portal, and then suddenly after you refresh, it's at the bottom of the portal. (This could be very annoying if you were trying to click down the list on each folder in succession, because you would have to scroll, click, scroll, click. )

I need a better way to refresh the portals without causing them to snap!

[John Glenn]

P.S. realized that Go to Record/Request (Get (RecordNumber)) is easier than going to the next record and back (there may not be a next record).

It still snaps the portals.