Welcome to the forum.
The post you reference describes how to launch a script. It seems like what you are asking is what the script should do.
The script would look at your fields, then take an action (Like GoToLayout) based on what it finds:
If (Table1::Electricity = "Preset1" )
If (Table1::Electricity = "Preset1" AND Table1::Water = "Preset3")
ElseIf (Table1::Electricity = "Preset2" AND Table1::Water = "Preset2")
Etc, Etc, .....
Is this what you're trying to figure out?
Your button would then launch this script (look under Button Setup in Layout mode). Or you could use a script trigger such as OnRecordLoad or OnObjectModify as is appropriate to your application and use.
Okay, thank you for clarifying.
Here is what I have:
If [indicator_chosen::indicator_id = "1001" and indicator_chosen: preset = "1"]
Go to layout ["1_1001" (1_1001)]
If [indicator_chosen::indicator_id = "1001" and indicator_chosen: preset = "2"]
Go to layout ["2_1001" (2_1001)]
If [indicator_chosen::indicator_id = "1001" and indicator_chosen: preset = "3"]
Go to layout ["3_1001" (3_1001)]
If [indicator_chosen::indicator_id = "1002" and indicator_chosen: preset = "1"]
Go to layout ["1_1001" (1_1002)]
And so on for each indicator.
1) Now, is there anyway to perform a calculation to simplify this ongoing expression?
2) If I added a new Indicator, is there a way to automatically create a new table, and include a way to go directly to the new table within the above script?
More info needed.
How many layouts (permutations) are we talking about here? 10? 10,000 as your numbering scheme seems to suggest?
Please give some perspective.
How many tables do you have?
What constitutes the need to go to another layout?
Are any of the myriad layouts similar enough to each other to use one layout for a group of permutations?
Also, be careful about confusing "Tables" with "Layouts" as your post suggests.
More information on the task you're trying to achieve will help generate a better solution or approach.
Originally I was going to have individual tables for each layout, so 25 Indicators times 3 Presets Each = 75 Tables, but after your suggestion,
I'm going to use 3 Layouts, 1 Table for each Indicator, so 75 layouts, 25 tables.
I'll try to illustrate an example as specifically as possible.
A user picks the Indicator Electricity.
A user then picks whether to use Preset 1, Preset 2, or Preset 3;
# A user would choose the preset to use depending on what information they had. They would choose Preset 1 if they had the square footage of the building, Preset 2 if they had their electricity bill, or Preset 3 if they had the exact amount of kWh.
# The user would want to use the most specific preset, so they would want to use Preset 3, but could use 1 or 2 instead.
# Within each layout, entering data will result in a calculation of CO2 emitted.
The user selects Preset 3.
The user goes to the layout for Electricity, Preset 3, and adds in the amount of kWh.
# The table (now including values added from Layout Preset 1, 2, and 3) would add the amount of CO2 emissions together to get a total CO2 emissions for that entry. One entry would only have a value from 1 Preset.
Hopefully this makes it clearer.
What about 3 layouts per indicator, 1 Table TOTAL. Why separate the tables for each indicator?
75 layouts (76 including the overview where Presets are selected)
1 table that holds all the data for that particular user.
Now you're controlling which fields the user has access to, and your calcs can be based on case statements which look at which Preset was chosen
Case ( field1 = Preset1 ; sqft * 16.85 ;
Preset2 ; (EndReading - BeginReading) * 0.325
Preset3 ; kWh * 0.325)
or some such.
The point being that it's all one table.
From your original post, the 25 buttons would run scripts (25 scripts total, 1 per button) looking at the choice made and steering to the correct layout.
With only 25 very short "steering" scripts, I'm not sure it's worth making a shortcut for nomenclature.