FME GUI Type Documentation

This is the documentation portal for FME GUI types. Use the menu on the left to select which GUI type documentation to view.

FME(R) 2024.1.3.0 Build: 24628 Date: 20241010

Introduction

GUI types are used to describe and organize elements of the user interface in a simple, intuitive manner. They are used mainly to outline custom setting boxes for formats and transformers. The graphical elements these types create are used to create input fields within dialog boxes; for example, the input settings for a transformer. These types are parsed by an interpreter, where then the interface is built.

Please note that some GUI types are deprecated or internal-only. Such types have a note in the description.

Common Arguments

Most GUI types share a set of common arguments. They are:

Suffixes for GUI Types

_OR_ATTR.
This suffix can be added to any GUI type. It is typically only added to transformer parameters. Adding this means that the user can specify an attribute value rather than just a literal for the transformer parameter. In addition, this will allow the user to create expressions and conditional statements. It is important to realize that when you do this, the underlying implementation in the transformer must be able to handle spaces in the parameter value even for _ENCODED types.

_ENCODED.
This suffix means the value of the parameter will be FMEParsableText encoded. Any parameter that could contain international characters will need to have this suffix as standard FME is system encoded thus can lose characters. This is also useful for parameters that could contain 'special' characters that have relevance to the FME parser such as space or semicolon. For example, a TCL script might contain the line...

if {[file exists $filename]}
...but when embedded in a workspace/mapping file the line would be represented as...

if<space><opencurly><openbracket>file<space>exists<space><dollar>filename<closebracket><closecurly>
...that way there's no way the parser will choke over unexpected characters.

This suffix can be added to any type but is typically only added to string related types like STRING_OR_CHOICE. TEXT_EDIT_ types are already implied to have this suffix so adding it is redundant. FMEParsableText encoding is not a standard encoding but unique to safe software. The backend is responsible for decoding the parameter value if appropriate.

_OR_ATTR_ENCODED.
The above two suffixes can be combined.

Delimiters for GUI Types

The amalgamation GUI types like MULTIPARAMETER and GUI_LINE_TABLE require a delimiter to allow the values to be flattened to a string. The delimiter chosen must NOT be a character that will appear in any parameters values within the container.
This means that the delimiter must be one of the FMEParsableText encoded characters.
These are:

< > & / \ ' $ @ space , ( ) { } [ ] ;

However, of these, a number are not usable because of the following conditions:

String parameters within the GUI_LINE_TABLE or MULTIPARAMETER should be either TEXT_EDIT or of type _ENCODED to ensure the user can not type in a character that matches your delimiter

Usage and Syntax in Transformer (*.fmx) Files

Usage and Syntax in Reader/Writer (*.fmf, *.fmi) Files