As always with Filemaker, there is an awkward workaround:
Place a field with content from the related table - Be sure to have a field with content. (For me, I always have a numeric field containing a 1. An old habit (before there was a Count function for example) that still is a good one.)
Fill the field with white, and set Hide Object If: Self = 1. Since there is no calculation made in the non existing related record on the last portal row, there will be a white rectangle visible. And the "Self" funciton is not dependent of any related objects, making it workable in all situations.
However; This doesn't work if you have Alternate Row State turned on (there will be a visible white rectangle), unless you want to create *two* rectangles with different colors, and then.... Well, it's a stupid workaround!
The objective is to make a function that always works, no matter what. Any more ideas?
Sorry, as usual I forgot to mention the whole setup...
One of the reasons to use this kind of setup is how easy it is for the user to enter data. For example notes about an order. What I want to say is that I still want some fields (at least one) to be visible in the portal.
Take a look at the attached picture.
This way, the user has the option to use the Add icon *OR* to just start write in the note field.
Ie; I still want the last row to be shown, but not all the objects....
However, Filemaker hasn't provided us with a "Don't show this object if there is no related record" function.
Not at all true. There have been lots of examples of this ever since hide object when was introduced.
Just point the calculation to a field that will always be populated if the record exists; such as the record ID of the child record.
No, I think you are wrong.
As I mention I don't want a proprietary calculation, I want a calculation that works in *all* portals. Which a "Don't show this object if there is no related record" function would have done. Just as I wrote.
But if you know of such a function, please let me know.
Bruce gave you a hint. Hide the object when record ID is empty. That will be applied for all the records in the portal, and only for the last the icon will hide.
Okey. I must be extremely bad at explaining myself.
A "Hide object when Record ID is empty" does only work with one relation.
With my example above, you are not able to copy the text "IsEmpty( Client | Note::ID )" and paste it in the Order Layout with a portal that show info from the Order::Note relation.
Or have I missed something very obvious?
That is: I want ONE solution that works with ALL PORTALS AND ALL RELATIONSHIPS.
Or: A "If there are no valid relationship, don't show this object" function.
If you have 100 portals in a solution, this kind of function would save a lot of time.
I don't know how I can explain myself any better.
You are not going to get what you want.
Thanks for the answer(s)!
Solve the problem by looking at your own picture.
What do lines 1 and 2 have and missing in line 3 - the related record creation line ?
Yeah. The creation date. Or timestamp, or whatever.
Use it in your hide formula.
But that's not the generic solution he's looking for. You need to correctly name specific fields for the table in question.
You can use your "habit" in "Hide object when" calculation.
Evaluate ( "not IsValid(" & GetLayoutObjectAttribute ( "p1" ; "source" ) & "::one)" )
where "p1" is the portal object name (you need), "one" is the field name you always have.
This is half answer that portal name should be unique in a layout, so if you have 2 or more portal the name in calculation should be changed.
It's very bad thing that Self function can't get object name.
That could be one step closer.
Still, if you need to change the Object Names you could as well go with a relationship calculation. Which would work even if field and/or table names are changed, while formulas with hardcoded object names would not...
One of the things I like about FileMaker is the ability it gives us to create workarounds. The IsEmpty ( relatedPrimaryKey ) suggestion already made is perfectly serviceable. All it requires to adapt it to multiple portals is to paste the expression and repoint the field in question. It takes little work to implement and it works. If anyone can come up with something more generic still I'll be pleased to swap it in. Perhaps you can think of a way, Andreass. Make a custom function for us all! Many features that have been added to FM over the years started life as clever workarounds designed by a user.