Creating new record in filtered portal

[jackfeuer]

I am having a problem with a filtered portal in an app I'm developing. When a user creates a new record in this portal, FM over-writes the user-entered value in one of the fields (a field involved in the filter).

I understand why it's happening, but I need to find a way to beat it, if I can.

Here's the situation: I have a portal which users may filter by selecting a value from a pop up. That selected value is then used in the portal relationship to select only matching records. The pop up values are from a user-defined vocabulary, let's call them UserValue1, UserValue2, UserValue3, etc. I allow the user to select any one of those values or to select "All".

If the user selects "UserValue1" only portal records containing that value will appear. If the user selects "All", all records will appear.

Because the values are created by the user, I can't hardwire the relationship to any specific set of values. So I'm creating the relationship by converting the user's selected value into a range for purposes of the portal relationship. Thus, if the user selects UserValue1, the relationship selects a range from UserValue1 through UserValue1 -- which selects exactly the value the user requests. If the user selects "All", I select values from "a" to "zzzzzzzz" -- which accepts all values.

This works fine for display, but it's given me a problem when the user creates a new record in the portal.

When a new record is created, the user must specify a value in that new record for the field on which I am filtering. The user picks that value from a pop-up list. However, when the cursor hops to the next field in this new record, FM is replacing the user's selected value with the current "filter value". That is, if the portal is set to show "All" records, the user's selected value is replaced with "zzzzzzzz".

If the user returns to the field, the "zzzzzzz" can be replaced with a valid value, and the valid value will "stick". Is there any way I can get the original value to stick in the first place?

[LiveOak]

How about using globals and a script to add new values. Then the contents of fields and the creation of the new record can be controlled explicitly. You could also try basing the right side of the relationship upon a calculated field equal to the entered field. This way FM can't change the value.

-bd

[jackfeuer]

How about using globals and a script to add new values. Then the contents of fields and the creation of the new record can be controlled explicitly. You could also try basing the right side of the relationship upon a calculated field equal to the entered field. This way FM can't change the value.

-bd

These are both good alternatives, and I'll think some more about how to make them work in my specific situation. Each gives me some potential difficulties (see below), but I doubt that I'll find a perfect solution -- I have to balance the problems against giving up the "All" option.

For globals there's a data entry speed and convenience issue: There could be a dozen or more portal records to enter for each parent record, and the portal's default "last row = new record" behavior is easier and faster than requiring a specific button-push to execute the script. I also have a real estate issue on this layout, which has 5 of these portals, all of which would require the additional global fields.

For the calculated field, I'm concerned about the added size of the record from doubling up this value. Each record is very small, but there are hundreds of thousands (potentially millions) of them, and the calculated field would probably increase the size of this table by 1/3.