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) 2014 Build: 14230 Date: 20140112

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:

• <macroName>
  • The unique name of the macro. The value associated with this GUI element is assigned to this name. Note: cannot contain any spaces.
• <label>
  • The text that is shown to the user. Typically, <label> is the last argument, and thus any additional text (including spaces) are associated with this argument as well.

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 WWJD 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. WWJD 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.