Although at its simplest, text editing can be considered more or less the same as an INFLD field editing operation (particularly INFLD's multi-line mode), XTEXT allows for a much more sophisticated approach, which can be broken down into the following sub-operations:

Create the control: The subroutine allows you to create a new control for each text editing session, or re-use an existing one. Up to five separate text editing controls can be defined at any one time.

Load text into the control: You can supply text to be edited by specifying a text file (plain text or RTF), or by passing the text in a string buffer. Unlike INFLD, the control can also maintain its own copy of the text between editing sessions, so that it does not have to be passed back and forth with the application each time the control gains/loses the focus.

Edit the text: The control allows for a full range of typical editing capabilities that will be familiar to most Windows users. The application has the ability to define various aspects of the display interface (size, toolbars, menus, rulers, window style, whether to display control characters, etc.), the editing format (e.g. wrap, whether character attributes are allowed), and keyboard commands (i.e. which function keys are passed to the control vs. causing the control to return to the application.)

Retrieve text from the control: The application can request to retrieve the control's text automatically when the user exits the control, or as an independent operation such as when the changes to an entire screen are to be finalized. The application can retrieve the text directly into a string buffer, or indirectly via a text file. In the case of the string buffer, if the text is too large for the buffer provided, the application is given the option of allocating a larger buffer (using Dynamic Arrays (DIMX)) and retrieving it again, or retrieving it in multiple pieces.

Store the text: If you use the option for direct file i/o, then that can be your storage format. Otherwise, if you retrieve the text into a string buffer, the application is left to its own devices as far as storage goes. You might decide to use the ISAM-A variable length record capability, or perhaps just break it up into a series of fixed length records, or maybe even use INMEMO as a filing system.

Destroy the control: The control may be destroyed automatically at the end of an editing operation, or explicitly under application control, or implicitly (as with other A-Shell AUI controls) when the screen is cleared.

Printing: If text editing is limited to plain text, then printing can be handled as it is for any other text data (although you may have to deal independently with the question of how to format a variable-length string of text into a suitable printing format). Most likely you will find that A-Shell's GDI Printing directives //TEXTRECTANGLE and/or //TEXTINDENT and/or //XTEXT, along with the MX_GDICALC subroutine, are quite useful for printing variable-length blocks of text.

If the text editing is more file-oriented, and especially if it includes character and other formatting attributes (RTF), you may want to enable the ability of the control to print its own contents directly to a printer, more or less like a normal word processing application would (see TXF_TOOLBAR and TXC.TOOLBARMASK for adding the printer icon to the toolbar, and TXC.FMAPCTL to allow the F4 key to invoke printing.)

To embed RTF-formatted text directly into another A-Shell report, use the //XTEXT GDI Printing Directive.