Page tree

Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.


In the article Image management (In de Quaestor Knowledge Browser: Quaestor>Topics>Technical documentation) and QBinaries, it is described how to create, maintain and access a collection of images or documents that are presented when a particular parameter or value is in focus in the Knowledge Browser or Workbase. In this article we will depart from this mechanisms will leave these mechanisms behind and zoom in on the possibility to create (binary) databases and use them (by performing selections) during the modeling process.


Example 1, Use of data in the dataset with an |OPTION| script:

Assume you want to store a hull form offset table your want to store in table in a parameter HullForm$ because it is needed as part of an input file for hypothetical software for software to calculate e.g. hydrostatic properties.

HullForm$ is determined by means of a relation:


The first line you see is simply an explaination explanation (and not required).

The script between |OPTIONS|….| describes how, what and where to get the Telitab set you will refer to as HULLDATA#.


Please realise that the last item, "DATADATA#" # "ParentShips", defines the reference for HULLDATA# to the actual total data set. This is the data set for the selection as described by the script. In this case the data is available in the ParentShips object.

During calculation the system will look for this object in the current solution. If it is not found, it will look in the Dataset of the project and if it is not found in the project either, it will look in the Dataset of the knowledge base.

The line "HullForm$" "" in the script tells the system that at least a DETERMINED value of HullForm$ should be available to allow selection of a case. This means, that the result of the selection cannot be empty values for HullForm$, therefor Quaestor will pre-filter all these cases out of the total dataset. The selection of HULLDATA# will contain all other DETERMINED values available in the selected record. Also SHIPTYPE$PROJECT$ and CONDITION$ should  must be DETERMINED (thus available) to allow a selection.


By using the QUERY# function with this syntax: QUERY#(0, Arg_1$[:ParLab_1$],,,,Arg_n$[:ParLab_n$]) for HULLDATA#, you can make sure that already available parameters will be used to pre-filted fill the options.

For instance when the ship type is already defined earlier in the solution, or is available as starting data in the dataset, you can add the relation HULLDATA# = QUERY#(0, SHIPTYPE$) to make sure that OPTION1 already uses the value for SHIPTYPE$.


As alternative method to select data, in stead of making a reference to an object as done with "DATA#" "ParentShips", you can include the data in the |OPTIONS|….| script of the parameter. This is done in the following example



Let us explain what you see in more detail: 

@SUMMARY and @PICTURE are attributeattributes, they manipulate the behaviour of the knowledge based system comparable to all the Slots&Properties. Using the @SUMMARY attribute you tell the system to display an overview of the total selection made, based on the dialog through de the included data. @PICTURE tells  indicates that pictures should be displayed of which the references are given in the included dataset.


As mentioned the @PICTURE attribute defines that relevant picture information can be presented throught through a references to these images. For "OPTION4" this has been defined. For example, table 1:twind1 refers to an image "twind1" in QBinaries object in the Dataset (QBinaries is a reserved Quaestor object that can be used to store all knowledge base fixed binary data, see Image Management in Quaestor>topics>Technical documentation>).

Please note that, if another object is used as data source (as is done in Example 1) referring to images in the QBinaries will only work if the parameters used in the refered object have Value:Label as string values and a @PICTURE attribute in there their dataslot.

Example 3, Use of binary data in the dataset with an |OPTION| script:


Note: The text after ' is comment please do not use it in the knowledge base.


Although the object RhinoComponents contains both Name$ as  and Type$, it will not ask for the type if a value of Type$ is already available on the location at which a hull form file is required. So, if Type$="Hull form", the option dialog will not present the "Type$" options list and only leaves the choice for cases fulfilling Type$="Hull form".


The above selection mechanism is enhanced with a mechanism that will immediately export any binary data stored in the final selection result. This implies that in the above example the binary data contained in the selected Component$ case will be exported to the currently active working (project) directory. There can be more than one binary datasets included in a selection; all will be exported assuming they will have unique names. In this way, you can ensure that particular data is available to any used satellite program (in this example the CAD program Rhinoceros) in which it is addressed by a Quaestor-generated script.