Guess who just discovered Merge Variables?
They will do nicely.
The issue of using a global variable in a portal filter still exists for me. If anyone has an answer that would be great or if it can be confirmed to be a bug I'll report it.
Looks to me like global variables can't be used in a filter (though i'm surprised we're not warned of that when attempting to use one). Global fields can, so you could do what you are doing with the $$Variable, but set the value to a global field.
I don't see why a global variable can't be used in a filter expression, but getting the portal to update after the value is changed will be an issue. I don't know of an alternative to using Refresh WIndow [Flush Cached Join Results]--which can trigger a significant performance "hit" on getting your layout updated when using a global variable.
I'm about to leave for the office, so I'll test this in fmp12 when I get there...
Just ran a quick test. And portal filters do work with global variables, but it takes that refresh/flush script step to get changes to the variable's value to get the portal to update. With fields used instead of variables, there are alternatives to Refresh/Flush that don't have a big of a performance hit.
Thanks again Phil,
I went back to the training manual and reread about global fields. I had forgotten they could be used as local memory variables.
They will be getting a work out.
What may not be in the training manual is that if you include the global field in the relationship with a cartesian join operator (x). Modifying the value in the global field will update automatically without any need for scripting in most situations and with very limited scripting that avoids Refresh Window in others.
Of course, if you are going to include the field in the relationship, you may not need any portal filter at all.