Populating Fields with a Menu Choice

[Relational Monkey]

Hi. I'm trying to figure out how to make a global menu selection (up in the header) and that selection populates a field with the contents of whichever field was selected in the menu — know what I mean? Sort of like this:

 

Furthermore, I'd like to be able to possibly script this such that the result field in every record in list view gets altered simultaneously by the global selection.

 

I'm unsure whether this is a script-able thing or something else, like a calc. I'm reasonably clever, but I probably need you to spell it out for me. Thanks for your guidance.

[comment]

If I understand correctly (not sure I do, though), you want to have a global field, say gChoice, in the header, and make the Result field a calculation field along the lines of =

Case ( 
gChoice = "Choice 1" ; Choice 1 ; 
gChoice = "Choice 2" ; Choice 2 ;
gChoice = "Choice 3" ; Choice 3 
)

This needs to be smartened up in order to prevent it from breaking if you rename one of the Choice X fields.

 

 

Note that the calculation will be unstored. You didn't say what the purpose of this exercise is - in general, you want to keep down the number of unstored calculations shown in List view, since they need to recalculate in real time.

[Relational Monkey]

I'm trying to make a way to print a list of a variety of figures (say, 6 fields per line, left to right, in columns) that the user can choose before printing. So, if there are 20 possible fields to choose from, say, you can choose any 6 you want on the list (per line) instead of having to make too many print layouts for different purposes. Obviously, I'm just going for one "column" and can extrapolate the rest, with your help.

 

As for the unstored part of it, it doesn't matter as much if it needs to recalculate on the fly, since I'm only planning on it being used in a print layout, but if there was another way to store the last configuration when the file is opened again (it will be on a hosted server) that would be even better.

 

Thanks again!

[Relational Monkey]

Thank you. Your basic structure is doing what I'm thinking of. I'm going to see if I can refine it into something resembling my idea. Any advice on how to make the choices made in each menu feel sticky until changed would help a lot.

[comment]

So, if there are 20 possible fields to choose from, say, you can choose any 6 you want

 

In such case I would make both gChoice and Result repeating fields (with 6 repetitions).

 

 

Any advice on how to make the choices made in each menu feel sticky until changed would help a lot.

 

You would need to store the choices in a regular (i.e. not global) field in a table of Users. Then have your start-up script populate the global field, using the values stored in the user's record in Users. Or use the stored values directly, if you have a relationship between the report table and the Users table.

[Relational Monkey]

Thanks, I managed to mock up the basic idea, with 5 columns of data.

 

What is the  technique to prevent it breaking, with renames, etc? I think I need to do more research to maximize efficiency in the calculation. The more possible case fields I add, it's gonna let long.

[comment]

What is the  technique to prevent it breaking, with renames, etc?

 

it may be irrelevant in light of your subsequent clarification. It doesn't seem like you're going to present your users with a value list of the actual field names, are you?

 

 

I think I need to do more research to maximize efficiency in the calculation. The more possible case fields I add, it's gonna let long.

 

The length of a calculation has very little to do with its efficiency. The Case() function exits at the first test that returns true. With 20 choices, that's an average of 10 tests to perform (assuming a uniform distribution of choices). I don't think that's something worth worrying about, particularly if this is going to be used only when printing/viewing a report.