Is there any calculation that can have the portals populate horizontally?
Use a grid of one row portals, each with the next portal row record as the initial record. In the example above, that could result in 18 different portals. But sometimes you can get what you need setup by using a list view where each row of your grid is either a different record or different sub summary layout part.
Many Thanks Phil
I was going to go down that route but wasn't sure if there was another way.
So I have set up a 7 x 5 portal grid which will display up to 35 records. If I have more than 35 records how would I get the portals to fetch the next 35 if they exist after filtering? I had thought of using tabs and repeating starting 36 etc but I could have 200+ records!
That's one of the limitations of a horizontal portal that can take some thought and experimentation before you hit on the best option for your solution.
But what "filter" is this? That's new info not in your original post.
It could be possible to set filters that work off a a global field. The filter expression you'd use would depend on what data is present in your database. One option is to use a filter expression with GetnthRecord to filter the portals to specific subsets of the total group of related records.
PortalTable::PrimaryKey > GetNthRecord ( PrimaryKey ; GlobalField * 35 - 34 ) and PortalTable::PrimaryKey < GetNthRecord ( PrimaryKey ; GlobalField * 35 )
There are other options. A last portal in the grid can be given a scroll bar to show 36+ items.
And you may be able to set up a list view where you would have a row of 7 (or 5 ) portals with a found set of 5 ( or 7 ) records to show a grid of 35 portals. If that can be made to work, finding the next 35 is simply a case of finding the next set of records.
the portals will be filtered to show the records I want ie all the blues or greens etc or all colors!
The filter expression you mentioned. Can you be more specific what you mean as Im not sure I understand how to achieve this as i'm still learning FM.
You mention list view. Can a list view be shown on a layout?
What relationship do you use for the portal? What match fields do you use?
at the moment the relationship is set to all (X) ColorID
I haven't set the match fields yet as Im trying to get the layout of the portal set up first using (all) records, after I get that I think I should be able to work out how to filter the different colors! in saying that it will be very unlikely that I will have more than 35 of each color.
At the moment its getting the portal to be able to go to next 35 etc Im interested in getting to work.
Yes, but the relationships are needed in order to get your layout to work.
I'd update your relationship to use the color as a match field so that you don't have to refer to it in the portal filter. That will keep the filters simpler and everything should update faster as well.
It's been a while since I messed around with this idea so I'm concerned that I might get a detail wrong. I remember needing extra table occurrences last time, but I think I wasn't using a portal filter either....
I think this would work as the portal filter to set on all 35 one row portals such that you can enter or select a value in gRecordSet--a global field and get the portals to update to show different groups of 35 colors from the same color group:
If you don't already have one, add and update a field for an auto-entered serial number, __pkColorID. That may be what you already have for ColorID or I can read that to be the ID that's the same value for all Reds and a different value for all blues etc. You'll need both such fields for this to work.
Define this relationship:
LayoutTable::gRecordSet X Colors::anyField AND ---> this is a special use of the X operator that forces filtered portals to update automatically
LayoutTable::ColorGroup = Colors::ColorGroup (I'm deliberately not using ColorID anywhere as I'm not 100% sure what it is.)
In this relationship, select a sort option that sorts Colors by __pkColorID in ascending order.
Now set up all 35 one row portals with this filter expression:
Colors::__pkColorID > GetNthRecord ( Colors::__pkColorID ; LayoutTable::gRecordSet * 35 - 34 ) AND
Colors::__pkColorID < GetNthRecord ( Colors::__pkColorID ; LayoutTable::gRecordSet * 35 )
If I have this all correct, Enter a 1 in gRecordSet to get the first 35 related records. Inter a 2 to get the next 35 and so forth...
I Have been playing around with this and seem to be getting good results.
I have two questions if you have the time to answer?
When I made another occurrence of the color table in a new portal and set to X on LayoutTable::anyfield , I can't get all the color records to show!
Im getting the first record from the sorted portal you helped me with on all my rows in the new portal. is it possible to make the original portal show all records? and I could avoid using the second occurrence?
Secondly is it possible for me return multiple colors to my portals ie; red and blue?
LayoutTable::gRecordSet X Colors::anyField AND
LayoutTable::ColorGroup = Colors::ColorGroup
won't show all colors due to the second pair of match fields.
LayoutTable::gRecordSet X Colors::anyField
Should work to show all colors in a portal, provided that your portal is not filtered.
There are several ways to show your colors from more than one color group. The simplest is to use two records on your layout. Record one can match to blue colors and record two can match to red.
On the other hand, the ColorGroup field can be a text field and you can put the needed values for Red and Blue color groups in the same field separated by a return. Put ColorGroup on your layout and format it with a check box group of colors and you can easily generate such a list just by clicking different check boxes.
Hi Phil could you take a look at this for me?
Im only getting round to setting up your solution.
getting peculiar results! I set it up as your demo apart from changing the portal number to 10 just to get it working!
If I get a result of less than 10 records the portals do not populate. Ten or over and all ten portals populate but I cant get the portals to show the next set. Colors::__pkColorID > GetNthRecord ( Colors::__pkColorID ; LayoutTable::gRecordSet * 10 - 9 ) AND
Colors::__pkColorID < GetNthRecord ( Colors::__pkColorID ; LayoutTable::gRecordSet * 10)
We do have a problem that I hadn't considered. Colors::__pkColorID < GetNthRecord ( Colors::__pkColorID ; LayoutTable::gRecordSet * 10) returns an error if there is no such Nth record to access and this keeps the portal value from evaluating as true for any records when that happens.
We might have to set up something like:
Colors::__pkColorID > GetNthRecord ( Colors::__pkColorID ; LayoutTable::gRecordSet * 10 - 9 ) AND
If ( IsValid ( GetNthRecord ( Colors::__pkColorID ; LayoutTable::gRecordSet * 10) ) ;
Colors::__pkColorID < GetNthRecord ( Colors::__pkColorID ; LayoutTable::gRecordSet * 10) ;
) // If
Hi thanks for getting back me. much appreciated
I set the calculation up as described and I'm now getting the sorted records showing if less than and equal to ten when "1" entered in gRecordSet
But getting nothingin the portals if I enter 2 3 etc. any thoughts?
When you change the value of gRecordSet, then run a script with Refresh Window [Flush Cached Join Results]
Do you then get the records to appear in the portal?
If not, I'll run a few tests. I have this nagging feeling that we need to use two table occurrences of the portal's table--one for the portal and one referenced in the getNthRecord funcitons--but I was thinking that wouldn't be necessary with a filtered portal--only if the "filter" were match field based...
I Ran a flush Cached Join but it didn't help.