SCENARIO$ enables enables the definition of a specific process of input and calculations

Syntax

...

Arguments
InputPar can be more than one parameter seperated by comma's and are parameters defining input. The parameters should have an @INPUTSOLUTION and @SCENARIOCHOICE attribute;
GoalPar can be more than one goal parameter seperated by comma's and the word "SUBGOAL" (see example). GoalPar are all parameters defining calculations. The parameters should have a @SCENARIOCHOICE attribute.
Furthermore, GoalPar parameters should be either string or Telitab parameters initiating additional calculations. Because in addition to the identifiers of the calculation steps, GoalPars are (or can be used as) result containers;
...
Additional the the optional attribute the all usual attributes can be used to manipulate layout (see Documentation of knowledge ). Usefull additions are:
Add color to scenario steps, otherwise all steps will appear in the color defined as input). Simply select the relevant parameter and choose a "Cell color" in the Slots & Properties window;
Use the @ORDER:[number] attribute to give an order to the presentation of the scenario when finished, otherwise an alphabetical order is applied;
All parameters used in the scenario function should be of the string type (string or TeLiTab) and should have the Determined by property USL (see Slots & Properties);
Parameters used in the scenario function should be in or under the "Top Goals/Undifined" node of the knowledge base;
By placing "SUBGOAL" between the SUBGOALS (see the example below) you indicated that the next goal will use the input and results of the previous SUBGOAL. You place it behind the goal you want to reuse the solution as part your following goal. Usually you want this so it is adviced to add "SUBGOAL" between the SUBGOALS at all times.
...
Ordening the design / engineering / calculation process. With scenario's you are able to define clear steps and let these be used only while still being able to use the reasoning mechanisme (the Quaestor intelligence of find relations to calculate parameters) to finalise without compromissing to much;
In combination with the Process Manager window it reduces complexity to start, continu and/or redo these processes;
All data requested in the INPUTSOLUTION parameters are automatically stored in the dataset selected for the process;
...
Give input you know that is always required (so no reasoning requried)
Perform a calculation;
Create a report;
...
In this relation TotalCostsScenario$ is relation is the scenario parameter, this parameter will communicate about the progress of the scenario in words like "In progress" or "Completed".
...
An example for the above input solution:
RequiredInput# = "Required input finished..." + LEFT$(CarName$ + FuelInstallation$ + + Weight$ + STR$(BuildinCosts + FuelEconomy + AmountKm + Years), 0)
By using the LEFT$ function, you force Quaestor to request the parameters inside this function for the INPUTSOLUTION.
An example for the subgoals:
TotalCostsCalculation# = TELITAB#(0, CarName$, FuelInstallation$, Weight$, BuildinCosts, FuelEconomy, AmountKm, Years, TotalCosts)
and
ReportGeneration# = TELITAB#(0, Report$)
CarName$, FuelInstallation$, Weight$, BuildinCosts, FuelEconomy, AmountKm, Years, TotalCosts and Report$ can be any input or calculation.
You see that we still use the Quaestor reasoning for each separate solution. We only pre-discribe the order in which these (3) relations have to be analysed and make a difference between relations to ask input (an you want to save in the data set) and relations that calculate/create things.

Quick links: Function overview | Attribute overview | Constants overview | Dimensions overview