TEXTEDIT item type

Defines a multi-line edit field.

TEXTEDIT item basics

The TEXTEDIT form item defines a text input field with multiple lines. This type of element is typically used to handle large text values such as comments or addresses that would not fit in a single-line edit field.

Use a VARCHAR(N) or STRING variable to hold the data for a TEXTEDIT form item.

Defining a TEXTEDIT

Use the SCROLLBARS attribute to define vertical and/or horizontal scrollbars for the TEXTEDIT form field. By default, when not specifying this attribute, TEXTEDIT fields get a vertical scrollbar.

The STRETCH attribute can be used to force the TEXTEDIT field to stretch when the parent container is re-sized. Values can be NONE, X, Y or BOTH. By default, this attribute is set to NONE for TEXTEDIT fields.

Front-ends support different presentation and behavior options, which can be controlled by a STYLE attribute. For more details, see Style attributes common to all elements and TextEdit style attributes.

TAB and RETURN

By default, when the focus is in a TEXTEDIT field, the Tab key moves to the next field, while the Return key adds a newline (ASCII 10) character in the text.

To control the user input when the Tab and Return keys are pressed, specify the WANTTABS and WANTNORETURNS attributes.

With WANTTABS, the Tab key is consumed by the TEXTEDIT field, and a Tab character (ASCII 9) is added to the text. The user can still jump out of the field with the Shift-Tab combination.

With WANTNORETURNS, the Return key is not intercepted or consumed by the TEXTEDIT field, and the action corresponding to the Return key is triggered. The user can still enter a newline character with Shift-Return or Ctrl-Return.

Where to use a TEXTEDIT

A TEXTEDIT form item can be defined in different ways:
  1. With an item tag and a TEXTEDIT item definition in a grid-layout container (GRID, SCROLLGRID and TABLE).
  2. As a TEXTEDIT stack item in a STACK container.

Defining the widget size

In a grid-based layout, the rendering of the TEXTEDIT widget can be controlled with the SIZEPOLICY, STRETCH and SCROLLBARS attributes. GDC and GBC desktop front-ends implement only the SIZEPOLICY=FIXED behavior, where the size of the TEXTEDIT is defined by the height of the element in the form. With GMI and GMA mobile front-ends, the default is SIZEPOLICY=DYNAMIC, to adapt the TEXTEDIT size to its content. Use SIZEPOLICY=FIXED with GMA/GMI, to keep the width/height defined in the form file.

In a stack-based layout, the TEXTEDIT widget always adapts its height to the content/value of the field. You can control the minimum height of the TEXTEDIT widget with the HEIGHT attribute. If the field content is null and the HEIGHT attribute is not defined, the minimum size defaults to one line.

Field input length

By default, the input length in TEXTEDIT fields is defined by the program variable.

There is no need to define the SCROLL attribute, except you explicitly specify SCROLLBARS=NONE (in a grid-based layout).

Note: When specifying SCROLLBARS=NONE (in a grid-based layout), the TEXTEDIT field will limit the maximum input length to the number of cells defined by the screen item tag.

For more details about the SCROLL attribute, see Input length of form fields.

Making the TEXTEDIT read-only

Use the NOTEDITABLE attribute to prevent text modification by the user. This attribute is typically used to display a large piece of text that the user is not required to modify (for example, to show the content of a log file). Yet, the focus can still go to the field, if it is enabled.

Rich Text HTML support

Some front-ends can also support different text formatting based on a style attribute. You can for example display and input HTML content in a TEXTEDIT with the Genero Desktop Client. When this feature is enabled, the TEXTEDIT supports rich text editing. Depending on the front-end, different formatting options are available (bold, font size, and so on) and can be controlled using an integrated toolbox.

Note:
  • Each front-end uses its own technology to provide HTML support in TEXTEDIT fields. The HTML representation may vary between front-ends. As a result, the same HTML content may display in a different way on another front-end.
  • When using rich text, the FGL_DIALOG_SETCURSOR() and FGL_DIALOG_SETSELECTION() functions must be called carefully. Because of the rich text format, having a corresponding cursor position / selection between displayed text and HTML representation may be difficult, especially in the case of hidden parts.