1 of 1 people found this helpful
Yes, this is fairly common -- though unexpected -- behavior. Remember that, when in list view, the Header is displaying only the fields from the FIRST record in the list.
You might think that it wouldn't matter with a global field, but sometimes it does.
You could try using a global field from a different table so that it is less record dependant. I often build a table of globals into a file just for use in dialogs and selection fields such a this. This also helps reduce the number of fields needed in some tables.
Hi Stephen, thanks for your answer.
Actually, the global field already comes from a global table not linked at all to the layout base table.
Thanks. I guess all I have to do is wait for filemaker to change the behavior of the pop-up list in list view
Stephen, The HEADER "record" gets it's information from the ACTIVE records (not necessarily the FIRST record). This feature is useful if you want to show more "details" of a record in the Header (or Footer) while in List view.
It is a global field in the header from another table. The issue is that the pop-up will not pop and allow selection if the User has scrolled down the list so that the currently active record is no longer in view. It has nothing to do with what current record is displayed in fields in the header. :-)
Added by LaRetta: Oh, I see what you were addressing. And you are right - the header displays the active record and not just the first.
Thanks, LaRetta! I was just correcting Stephen's statement that header fields would be from the FIRST record. As you pointed out, they can be global (or non-related fields), too!
Just a thought from a newbie:
Is it possible to use a calculated field with the list command in the calculation.
IMHO all the values are listed in that field so it don't matter wich record is the active one.
I have not tested this but I'm only trying to learn from everyone.
Thanks for pointing out my boo-boo.
The reason I think of the header field that way, as tied to the first record, is that the problem with header fields in list view not working as expected if the active record is not in view has been around for years. And I have dealt with it by always scripting a step to go to the First record to avoid that problem when editing the header field.
It always works if you force focus onto the first record in the list, but, depending on the list layout, it's almost imposible to be sure any specific record except the First will be both active and visible while attempting to use the header. I've been scripting a Go To Record [First] as part of a script trigger since they were introduced just to avoid this problem. I've become so accustomed to doing this to assure the field works that I started thinking of the field as belonging with the First record.
No In this case the problem doesn't come from the content of the list but really just some display bug. Even with a custom value list that has no link at all with the current table, it has the same behavior