hide text object on a portal based on portal contents

[Clayton King]

There are two single-row portals on my layout (stacked in orange).

The first one shows a count of records where no Set is specified in the related Performances table.
The second portal counts records in Performances where no Singer is specified.

I'd like to hide the portals entirely based on whether or not there are no records to show; so if the count is zero, just hide it because it's not helpful information. It's colored red to alert the user that a set or singer hasn't been assigned.

In the example below, the portal circled in blue has 1 record because there is a song in the list that doesn't have a Singer assigned to it.
In the second portal (circled in red) there is one song that doesn't have a Set assigned to it.

When I correct those issues, I get this, which is expected. I'd like to hid the text objects "Unassigned" and "No Set" as well as the red portals altogether. Any thoughts?

[comment]

This is a cross-post. There are already 7 answers in the other thread:
https://community.claris.com/en/s/question/0D5Vy000004340nKAA/hiding-layout-objects-conditionally

A general advice concerning asking questions and solving problems: isolate the issue and provide a short way to reproduce the problem.

In this case, I would expect to see a simple file, with the minimum of tables/fields/relationships required to create a portal of the kind you describe. And a layout that contains one portal with one text object that you are struggling to hide - and not much else.

As it is, we are staring at a screenshot that doesn't tell us anything about the structure of the data behind it. It's like posting a picture of a car and asking "why won't the engine start".

But, there are 7 answers in the other thread - so apparently not everyone shares my views and there are doctors who are willing to write a prescription without examining the patient...

 

3 hours ago, Clayton King said:

I'd like to hid the text objects "Unassigned" and "No Set" as well as the red portals altogether.

That makes no sense to me. If a text object is inside a portal and the portal is hidden, then the text object is hidden too. And also, if the portal has no records to show, then the text object will not be shown either.

Here is a simple (!) file showing both.

hideportal.fmp12

Edited March 3 by comment

[Clayton King]

This is a cross-post. I was hoping to get more feedback from another group of people, and I appreciate that you, like me, are on multiple forums.

I agree that this makes no sense. The text objects are well within the portals to which they belong. I appreciate your taking time to create the simple (!) file, and agree that the behavior of portals described in it is expected behavior.

My file is not simple, and the layout behavior on the portal is producing unexpected results. I attempted to explain the basic data structure in the file to provide some context, and the basic premise of formatting objects. Hiding them conditionally should work and it doesn't. I thought perhaps someone out there in cyberland might think of something I missed.

I apologize if this is annoying to you. I promise it can't be as annoying as this issue is for me.

 

For what it's worth, I cloned the file without data, created a new gig, four singers, and used a Case statement to hide the portal. It worked exactly as expected. When I apply the exact same conditions on the original file, it misfire.

Edited March 3 by Clayton King
clarification

[comment]

18 minutes ago, Clayton King said:

For what it's worth, I cloned the file without data, created a new gig, four singers, and used a Case statement to hide the portal. It worked exactly as expected. When I apply the exact same conditions on the original file, it misfire.

See, you are already one step further towards a solution. A big step. Now the question is "is there some difference you are missing, or is your original file corrupted".

 

23 minutes ago, Clayton King said:

I apologize if this is annoying to you.

I didn't say it was annoying (it is, but that's not the point🙂). I tried to explain why it's not productive.

 

[Clayton King]

35 minutes ago, comment said:

Now the question is "is there some difference you are missing, or is your original file corrupted".

I have to assume there's corruption involved. I have no clue how to find what it is, but I'll do some searching. The only difference between the original and cloned files is the data itself, plus I deleted some fields off the original layout that have nothing to do with the portals in question...

[comment]

19 minutes ago, Clayton King said:

The only difference between the original and cloned files is the data itself,

Don't dismiss the possibility that the data in the original file is not exactly what you think it is.

Anyway, If you do a recovery on (a copy of) your original file, and the recovered file behaves as expected, you will know for sure.

 

[Clayton King]

4 minutes ago, comment said:

Anyway, If you do a recovery on (a copy of) your original file, and the recovered file behaves as expected, you will know for sure.

I did a recovery on the file and there were errors, but not sure what it means or what to do about it. I feel like it has to be the data itself because the clone I made with no data worked as expected.

2024-03-03 07:46:20.022 -0500    2024-03 SONGBOOK.fmp12    20402    ERROR: copy or rebuild of file blocks failed; try another option in Advanced Recover Options
2024-03-03 07:46:20.031 -0500    2024-03 SONGBOOK.fmp12    300    ERROR: Recovery of '2024-03 SONGBOOK.fmp12' failed

[Clayton King]

@comment,

I took a slightly different approach and change the autocalc on the field "Multi" which was based on RosterCount (this is a count of singer names in the record). The autocalc looks at the number in RosterCount and returns "Solo, Duet, etc."  using a case statement.

Case ( 
RosterCount=1 ; "Solo";
RosterCount=2 ; "Duet"; 
RosterCount=3; "Trio";
RosterCount=4; "Quartet";
RosterCount ≥ 4;"Multi"; "None" )

My hidecalc now uses this field to determine when to hide the "No Singer" text using a Case statement:

Case ( 
gigs_PERFORMANCES::Multi = "None";
0;
1 )

I've changed the portal color to white and the text to red; the idea all along is to make this portal an alert that something is missing. It now works satisfactorily. I could never get a red-filled portal to hide. The data would hide, but not the red portal itself.

I've applied the same methodology to the No Set portal with the same satisfactory results.

Thanks for the thought-provoking conversation. It was helpful, if frustrating.

[Søren Dyhr]

On 3/3/2024 at 7:48 PM, Clayton King said:

Case ( 
RosterCount=1 ; "Solo";
RosterCount=2 ; "Duet"; 
RosterCount=3; "Trio";
RosterCount=4; "Quartet";
RosterCount ≥ 4;"Multi"; "None" )

I don't know if it's any faster, but this does the same:

Let(
   theCalc =
   Choose( 5 - RosterCount; char( 0 ); "Quartet"; "Trio"; "Duet"; "Solo" );
   Case( IsEmpty( theCAlc ); "none"; theCalc )
)

--sd

Edited June 8 by Søren Dyhr

[comment]

54 minutes ago, Søren Dyhr said:

this does the same:

Let(
   theCalc =
   Choose( 5 - RosterCount; char( 0 ); "Quartet"; "Trio"; "Duet"; "Solo" );
   Case( IsEmpty( theCAlc ); "none"; theCalc )
)

No, it doesn't. It will never produce the result of "Multi" that is expected when RosterCount > 4. Instead it returns "none".

I am not sure what's the point of reviving a 3-month old thread, but if looking for a shorter formula (though not necessarily more readable or understandable to a beginner) we could use:

Choose ( Min ( RosterCount ; 5 ) ; "None" ; "Solo" ; "Duet" ; "Trio" ; "Quartet" ; "Multi" )

This is based on RosterCount being "a count of singer names in the record", therefore never empty.
 

Speaking of "readable or understandable":  I wonder how many people are aware that the expression Char(0) returns an empty string - which is normally expressed as "" .  I really don't see the point of obfuscating the code in this manner. Not to mention that some day Claris might acknowledge that this is a bug and make the expression return the actual NULL control character - which could have some nasty unexpected consequences if used in the manner you suggest.

 

Edited June 8 by comment

[Søren Dyhr]

3 hours ago, comment said:

No, it doesn't.

No, I just forgot "Multi" and 

 

3 hours ago, comment said:

Choose ( Min ( RosterCount ; 5 ) ; "None" ; "Solo" ; "Duet" ; "Trio" ; "Quartet" ; "Multi" )

AHHH yes, it's much much better, and do certainly not have to deal with neither "Void" nor "Null" 's ... because

 

3 hours ago, comment said:

Not to mention that some day Claris might acknowledge that this is a bug

 It's been discussed before, e.g. clearing a number- or container- field is made by a typecast, from text ... even though it just is a ("") - the script step Clear.. only deals with values present at the current layout. I have for a while used Case(0;0) as void'ing function with Set Field.

But the reason for bringing this up, this late ... is a mean to get even better ideas in my own development, and I was hoping for just the reply you gave here - it ticks all the boxes in my book! 

The benefits in using Choose( instead of Case(  .... could resemble the use of Switch in c++ and by it make the rendition/compilation a tad faster? I would not know...

--sd

Edited June 8 by Søren Dyhr

[comment]

50 minutes ago, Søren Dyhr said:

clearing a number- or container- field is made by a typecast, from text ... even though it just is a ("")

True, but if the MBS FM.DataType function is to be trusted, then Char(0) returns a Text result, same as "" does. So you're not gaining anything by it. 

Interestingly enough, GetAsNumber ( "" ) is also Text, but GetAsNumber ( "a" ) is a Number (although equally blank). 

Personally I see no problem in using "" to clear any type of field. And certainly in the current context the result is supposed to be Text, so "" is the shortest and most correct way to express a blank result.

 

1 hour ago, Søren Dyhr said:

benefits in using Choose( instead of Case(  .

I agree that Choose() should be faster, but I doubt you would measure a significant difference in the present example.