Is there a way to identify top row of portals?

Questions
1

I want to hide a field if it's the top row of a portal, is there some way to identify the top row of a portal? I tried to hide it if "Get (RecordNumber) = 1" but that hides all of them.

2

Use the field with the primary key to find the first item of the list displayed in the portal. In this example the field is called "id":

Let (
~firstID = LeftValues ( List ( portaltable::id ) ; 1 ) ;
portaltable::id & ¶ = ~firstID
)
2 Likes
3

Solved. Thank you!

1 Like
4

I wonder if GetNthRecord would be faster than getting the entire list and then using LeftValues?

Something like this:

Let (
  firstID = GetNthRecord( portaltable::id  ; 1 ) ;
  id = firstID
)
1 Like
5

the fasted "should be" PortalTable::MyUnstoredRecNum = 1 where
MyUnstoredRecNum := Get ( RecordNumber ) as an unstored calc in the PortalTable

4 Likes
6

same way (for fast performance) I needed the last portal and I used an unstored number field get(foundcount)) and the condition for hide or whatever is PortalTable::MyUnstoredRecNum =PortalTable::foundcount

1 Like
7 
Let (
  firstID = GetNthRecord( portaltable::id  ; 1 ) ;
  portaltable::id = firstID
)

This way it works without extra field in the PortalTable. Great!

8

A number of the record level commands (eg get (RecordNumber) ) act not on the portal but on the base layout. It varies based on how it is enacted in the portal.

A get(RecordNumber) command as a merge command works but the same command in a button bar segment label uses the underlying layouts record. Same effect in hide commands.

Out of curiosity, what’s the use case to hide the first record in a portal??

9

The client would like to have the most recent record to show all details and then a list of "all other" interactions. This issue has come up a few times with different clients and I finally broke down and asked instead of just asking them to live with it.

This specific use case was a few months ago, but I think it had to do with class goals.

The client wanted to see the last Goal that student had for a specific class with a whole bunch of details about it (who opened it, when it was opened/closed, the status, the type of goal, the long description)...

But then they wanted a list below that with all goals EXCEPT that one that just showed the goal title and subject and if it was met or not.

10

Ok. Here is a novel concept: in the portal setup dialog only show records 2 thru however many rows you want the portal to display. NOW that portal will NEVER show the first child record.

You will NOT be able to scroll to the first child record in that portal.

Make a second portal with one row, with all the detail you want in it.

3 Likes
11

Oh my, that's amazingly simple. Lol. Love it...

1 Like
12

Some additional enhancements:

  1. search FMSoup for "Ghost Portal" - interesting stuff for creating child records from the context of the parent.
  2. Add a button to the portal row with a popover that displays all the details you want about that row's data
  3. In the button setup dialog, set the "specify" to "true" (no quotes) or 1 (either is a boolean for true). Then when one clicks on the button, the STATE condition of that button will only impact that particular row's button. (Works in lists as well) Makes for a far cleaner UI. It is obnoxious when a clicked button highlights in every row, and this fixes that.
1 Like
13

I wish you could add popover buttons to portal rows. I've done the "make a new layout that's a popover window" for buttons in portals but it's such a pain.

I also wish we didn't have to hop through so many hoops for a ghost portal and that it was just a checkbox, but I've got hundreds of those scattered around.

Thanks good stuff!

14

@Kirk This is fantastic. I so seldom use the initial row specification for a portal such that I believe I would have overlooked this possibility. Thank you.

15

??? I use popover buttons in portal rows constantly. What's NOT working? OK, so you can't nest popovers in popovers, or portals within portals, but popover buttons? Works great!

Really simple - 1) set Create Through Relationship, and 2) create a one row portal from that child TO with the filter set to false and 3) place a SAVE (commit) button in that portal.
You can also just place a popover button in a ghost portal; the popover now exists in that context, so you can use more space for data entry.

The main (multi-line) portal can either be a separate child TO from the same context (without Create Through Relationship on), OR you can hide the fields in the main portal if a primary key does not exist (the ghost record has no substance (hence my nickname "ghost") and therefore no primary key until committed at which point the FALSE filter removes it from the Ghost Portal.

16

Oh your right, it's portals in those popovers that don't work... I usually just make cards in those instances, but would be nice if we could have portals in portals that way.

17

What I pretty much always want is the "add new record" to be at the TOP of the portal row. I've never found a use case where I want it at the bottom. If what you're calling a "ghost portal" is what I think it is I think I have two options:

  1. create two relationships and put the portal that allows creations in the top one and the one that doesn't in the bottom one. This makes things cluttered in my database design as I have dozens of these in each application and also means that when I change what's in the portal (i.e. add a new field, change conditional formatting) everything becomes a bit trickier because two tables.
  2. Use the same relationship and set the top portal to hide everything that has a primary key, and then manually hide every field that doesn't have a primary key in the bottom one.

I usually go with #2, but it's a bit of a pain, since some of the fields have other "hide and show" criteria based on user privileges.

It's not "hard" but it feels like such a waste, and I'm just wishing that Filemaker would just add a checkbox that says something like this "put fields to add new record at top of portal instead of bottom".

shrug...

18

In option2, No HIDE condition required for the one line portal. Set the multi-line portal (not the one line one that is filtered as FALSE) to HIDE everything on a portal row if no primary key. That way the abhorrent blank field set at the end of a portal with CTR on, will no longer show.

As far a "clutter" - place a popover button in the ghost portal with say, a PLUS sign as the icon. Nothing else in that portal except that button. Then when you click, the popover opens with the fields you want to enter data into, and clicking a save button, commits the records, clears the fields in the popover (they are not longer FALSE) and adds the record to the child table and hence the main portal. In this way, you can create a low real estate solution that you can use consistently across your solution (better UX).

NOTE: "Ghost Portal" is my name for this. When Create Through Relationship is on, a portal shows a phantom (ghost), record that does not really exist until it has content - at which point, it is no longer a ghost record. With the unique ability to write the foreign key automagically, the technique has a multitude of uses that are simpler than most alternatives.

1 Like
19

@Kirk Brilliantly simple and simply brilliant. :man_facepalming: I now feel really stupid as I have, on several occasions, used a much more complex solution to this scenario!