Is this a custom value list or a list of values from a table?
While we could set this up as a custom value list, I'm concerned that such would give the user too much freedom as in enables them to remove the "all" and "mixed" entries.
It's possible to set up a table of breeds as the source of values for the list and use a calcualtion field defined in that table to add in the "all", "mixed" and "-" values for the list:
List ( " All" ; " mixed" ; "-" ; BreedField ) //note the space used as the first letter of the first two terms
How you use the value entered into the global field from this value list depends on how you set up your portal filter.
Trim (globals::gBreed) = "all" or Trim ( globals::gBreed) = PortalTable::breed
is one possibility.
It's a custom list.
The list "Breeds" which is structured as: Mixed, -, breed 1, breed 2, etc.
This list will allow the user to enter new values - so it will change over time.
I need to take this list and add "All" as the first item so I can then use it as a filter on a portal and keep UI simple (my other two choice lists start with All).
I understand that the user could "break" the list/system if they happen to edit it incorrectly.
Then you simply need to add All as one of the custom values. But I caution that this is not the best option for managing your breed values. Your table ov breeds can be set up so that user can modify the values in the list by editing the data in the breeds table and this will protect your system from user error.
I wanted to do it script based/etc. so that when the user is entering an animal they don't see All...but it is available as the first item on the filter when I need to use the same core list as the filter list.
What I describe would do exactly what you have requested.
Here's a demo file: https://dl.dropbox.com/u/78737945/FilterPortalCatBreeds.fmp12
Notes: I cut a number of corners to keep the demo simple and to make it something that I could quickly set up. You probably wouldn't put a port to cat breeds on the same layout as your filtered portal but it shows how you can edit the "breed" values and yet neither "mixed" nor "all" appear in the list to be edited.
For smooth updates of a filtered portal, the "filter fields" should be included in the portal's relationship using the X operator.
Okay - I've been working with this for a bit now and applying some of it to my existing database.
I understand about half of what you did and implemented that with some tweaks. I broke out breeds into its own table and created two calc fields and two value lists (one for breeds-new and one for breeds-filter). In the breeds-new I added an option "Add Breed..." which I catch during an OOM trigger to invoke a dialog to enter the new breed (since i don't want to expose the breed table directly - only for admin/maint). In the breeds-filter I add the "All" item.
I use the breeds-filter with the all and have worked that into my portal filter calculations.
I still need to look further at how you setup the relationships (and I need to find a good primer on the Let command) since the way you do the filter is much more efficient then what I'm doing (relationship based vs. actual critiera).
Thank you very much for the demo DB!!!