Once you get pretty much familiar with scripting and you can create numerous *.fcs files there is time to get your job working on HiStruct. This brings one new issue - how to allow user to change input variables and how to take them into account. This is a story how I managed to deal with this trouble.

The first step I needed to do was to decide which variables are going to be input values - what can use on HiStruct change or define himself. If can be any value, list of items, action, string, etc. The complete list of input items (as we call it in FitInputItems.fcs) looks like this:

InputItemList   
InputItemInteger
InputItemDouble 
InputItemClass  
InputItemArray  
InputItemAction 
InputItemComment
InputItemString 

It is a common practice that input variables syntax starts with "in" and is located either in one common file that contains all inputs (which can therefore be extremely long and confusing) or in more files, always closest to the location of use (which makes clear usage but the inputs distribution is confusing too). I decided to define input variables in 5 main files that govern building parts. It could look like this:

inSheetingTypeOfInput := 0             # 0 = myMaxSpan, 1 = mySheeting
inMyMaxSpan    :=  ust.mOrFtFn(inMyMaxSpan_m, inMyMaxSpan_ft)
inMyMaxSpan_m  := 2.00                    # unit m
inMyMaxSpan_ft := 6.00                    # unit ft
inPanelOrientation := 0                # vertical/horizontal

Note 1: The input is always value, therefore if you want to choose from a list, the input gives the array position.

Note 2: Input above is ready to serve both templates in metric or imperial unit. Therefore there is "mOrFtFunction" that determines thich of the two is used.

Basic, one and only, master class that is used to define input is C:\GitHub\fcs-gsi_Common\FcsEntity\FitInputItem.fcs This rather extensive file contains numerous variables but not all are utilized for each item type. The most important ones are mentioned below. However, here you can study the complete composition of the input item. Usually, it is common to define input item by reference to resources:

 res.fit.***

gclass {InputItem}        filename "FitInputItem.fcs"

InputItemList     := InputItem{ ParameterItemType := 3 }
InputItemInteger  := InputItem{ ParameterItemType := 1 }
InputItemDouble   := InputItem{ ParameterItemType := 0 }
InputItemClass    := InputItem{ ParameterItemType := 4 }
InputItemArray    := InputItem{ ParameterItemType := 2 }
InputItemAction   := InputItem{ ParameterItemType := 5 }
InputItemComment  := InputItem{ ParameterItemType := 6 }
InputItemString   := InputItem{ ParameterItemType := 7 }

Separate file (usually) defines the input page on HiStruct. Basic item is a class:

InputPageSheeting := res.fit.InputItemClass{
    NameSpace     := NameSpace + "InputPageSheeting.",
    HumanName     := "Sheeting",
    PvcNeedsBreak := True,
    ClassItems    := [
        InputVariants,
        PanelDefinition]

Class is basically a chapter that brings title to following list of inputs. Its children (= ClassItems) can be any input item, including another class if necessary.

Note 1: Namespace is a property that is repeatedly used in all input items. It serves to define path to the particular variable. Therefore is it necessary to type it every time and keep the habit of composing previous Namespace + variable name ended with a dot (in brackets).

Note 2: Notice the PvcNeedsBreak property. This defines whether the InputItemClass will have its inner variables updated in PVC. If set to False, the InputItemClass might be vanile after user input is saved to PVC.

TypeOfInput := res.fit.InputItemList{
    NameSpace   := NameSpace + "TypeOfInput.",
    HumanName   := "Type of input",
    Identifier  := "building.sheeting.inSheetingTypeOfInput",
    ListOptions := [
       ["user purlin distance",   0],
       ["user sheeting",          1]
    ],
}

Identifier tells the path to the input variable (note "in" prefix of variable inSheetingTypeOfInput). Here the variable is defined in ../Building/MainSheeting.fcs

ListOptions is an array of arrays (= options of the combo box). Each list option can have 3 items: name which is displayed to the user, number which is used to overwrite Identifier and (optional) language key (not displayed here).

SpanInput := res.fit.InputItemDouble{
    NameSpace             := NameSpace + "SpanInput.",
    HumanName             := "Required purlin distance",
    NumericFormat         := "0",
    DefaultUnitString     := "m",
    VisibilityConditionStr := "building.sheeting.inSheetingTypeOfInput==0",	
    Identifier            := ust.identifierFn_mOrFt("building.sheeting.inMyMaxSpan"),
}

DefaultUnitString is being displayed right next to the input cell.

VisibilityConditionStr is a condition string that determines when this particular input is visible. In this case user set span only if the input type is "user purlin distance" (see above chap. 4.2)

WallSegments := res.fit.InputItemArray{
    NameSpace         := NameSpace + "WallSegments.",
    HumanName         := "Wall segments",
    Identifier        := "building.sheeting.inWallSegments_CtArray",
    EditableCount     := True,
    ElementPrototype  := act.building.wallSegment_ClassTypeInputItem.ParameterItemClass,
    ElementPrototypes := [ act.building.wallSegment_ClassTypeInputItem.ParameterItem ], 
    Actions           := [] 
} 		

Input item action is used to generate particular output. It can be either report, DXF file or ESA file.

For exporting a document I suggest to use the following base function which is "filled by" 4 variables:

ReportExportClassFn := vn, des, hn, img => res.fit.InputItemAction{
    NameSpace            := NameSpace + vn + ".",
    Description          := des,
    HtmlContent          := hn,
    CssStyleClass        := "fcs-parameterItem-inMenuButton",
    IsReadOnly   := True,
    ActionName           := "Outputs." + vn,
    NavigationUrl        := "Projects/Report?id=##componentId##&reportName=img }

Note: reportName in navigation URL tells the path to the particular report. In case there are more reportin in the same sub class it can contain something like reportName = building.outputs." + img

Note2: Take care for html vs hmtl typo. In some branches, its corrected, in others it is not.

For exporting a DXF file I suggest to use identical base function, where the difference is in NavigationUrl parameter only:

NavigationUrl        := "Projects/ReportDxf?id=##componentId##&reportExpression=building.outputs."+img }

And for exporting SCIA Engineer file there is a third variant of NavigationUrl (the rest remains):

NavigationUrl        := "Projects/DownloadSciaFile?id=##componentId##" }

description to be added....

There is a possibility to define the InvalidationScope and SceneInvalidationScope. This help in user interaction with HiStruct, the delay time is much smaller and user does not have to wait for the input page (or scene) to update. The options are:

InvalidationScope = "Global" or ""; "Item"

• Global or empty automaticaly do validate the whole input page

• Item changes only the input item itself, it does not affect the other input items

  SceneInvalidationScope= "Global" or ""; "None"

• Global or empty automaticaly do validate the 3D scene

• None does not affect the scene

There will be also options for validating only the parrent of the input item or some specific group of items (defined by name).

Editability of input items: Use property IsReadOnly for most InputItems or IsEnabled for InputItemAction.