This document covers the following topics:

• Types of Natural Editors

• Invoking a Natural Editor

• Editing Data Areas

• Viewing Dialogs, Classes and Adapters

• Problems in Your Natural Sources

• Parsing Dependent Objects

• Unicode and Code Page Support

• Bidirectional Language Support

• Source Header

• Line Numbers

---

Types of Natural Editors

The following table indicates which type of editor is used for a specific object type:

Icon	Object Type	Extension	Editor
	Program	NSP	Source editor
	Class	NS4
	Subprogram	NSN
	Subroutine	NSS
	Function	NS7
	Copycode	NSC
	Helproutine	NSH
	Text	NST
	Dialog	NS3
	Adapter	NS8
	Global data area (GDA)	NSG
	Local data area (LDA)	NSL
	Parameter data area (PDA)	NSA
	Map	NSM	Map editor
	Data definition module (DDM)	NSD	DDM editor

The above icons are used for the sources in the Navigator view, in the Natural Navigator view and in the Dependencies view.

They are also used in the Natural Server view. On a Natural server, however, Natural objects can consist of the source, the generated object (for example, a generated program) or both. The difference is reflected in the icon. Therefore, in the Natural Server view, the above icons can be shown as follows (example for a program):

Icon	Description
	Without a green ball and not gray: only the source of the object is available.
	With a green ball and not gray: source and generated object are available.
	With a green ball and gray: only a generated object is available and no source.

Invoking a Natural Editor

A Natural editor is invoked when you open an existing Natural object or when you create a new Natural object.

You can open an existing object either from a Natural project in the Eclipse workspace (Navigator view or Natural Navigator view) or directly on the Natural server (Natural Server view). For further information, see the following sections:

• Editing Objects in Working with Natural Projects in Local Mode.

• Editing Objects in Working with Natural Objects in Natural Server Mode.

You can create a new object in a Natural project in the Eclipse workspace (Navigator view or Natural Navigator view). For further information, see the following section:

• Creating Natural Objects in Working with Natural Projects in Local Mode.

Editing Data Areas

NaturalONE makes use of the Natural source editor for data area editing. The wizard for creating new objects generates a skeleton for the DEFINE DATA statement. Within this skeleton, you are able to write the variable definition. Editing of the data area is well supported through the Natural parser.

Data areas that are downloaded from a Natural server are automatically normalized. This means that the internal data area format is converted into a DEFINE DATA statement. The benefit is that the data area can be defined quickly and that versioning of the data area source is possible. When you use the Build Natural Project or Upload command, the normalization is reversed: the internal data format of the Natural server is then generated from the DEFINE DATA statement.

Viewing Dialogs, Classes and Adapters

NaturalONE does not support dialogs and classes (see also Are all Natural object types supported? in Frequently Asked Questions). However, it is possible to view (and even edit, although this is not recommended) the source code of such an object using the source editor. With NaturalONE, it is not possible to create these objects from scratch. The same is true for adapters which are generated by Natural for Ajax.

Problems in Your Natural Sources

When a syntax error is detected in a project after an object has been saved, or when a compiler problem is detected in a project during a server update (that is, when a source could not be cataloged on the server), this is indicated in the Navigator view or in the Natural Navigator view.

In the case of a problem, the icon of a project contains a corresponding decoration. The subnodes containing the problem also contain the decoration in their icons.

The Problems view shows the corresponding error message(s). When you double-click an error in the Problems view (or when you select the error and then choose Go to from the context menu), the corresponding line in the editor is selected.

Two types of errors are shown in the Problems view. Errors starting with "NAT" are Natural system error messages which are issued by Natural on the server. Errors starting with "E_" are issued by the local NaturalONE parser when an error is found in the editor.

When you select an error in the Problems view, the error message is also shown at the bottom left of the Eclipse window.

In the Natural preferences, you can specify whether information is to be shown in the Problems view. See Source Editor in Setting the Preferences.

Parsing Dependent Objects

When syntax parsing of dependant objects is enabled in the Natural preferences (see Natural > Builder in Setting the Preferences), any dependent objects containing syntax errors are shown with an error marker in the Navigator view or in the Natural Navigator view. In addition, a corresponding error message is shown in the Problems view.

A dependent object is, for example, a program which uses the fields from a data area. If the data area is changed, this change must also be considered in the dependent program.

In the Natural preferences, you can also specify that syntax parsing is to be stopped after the first error (see Natural > Builder in Setting the Preferences).

Depending on your settings, syntax parsing is either done automatically or can be started manually. This is explained in the topics below:

• Automatic Parsing

• Manual Parsing

Automatic Parsing

When automatic parsing is enabled, all dependent objects are automatically parsed after a Natural source has been saved.

Automatic parsing can be enabled and disabled using the Parse Syntax Automatically command or by setting the corresponding option in the Natural preferences (see Natural > Builder in Setting the Preferences). When you choose the Parse Syntax Automatically command, the setting in the preferences is adapted accordingly, and vice versa.

When automatic parsing is enabled, a checkmark is shown next to the Parse Syntax Automatically command.

To enable or disable automatic parsing of dependent objects

• From the Project menu, choose Parse Syntax Automatically.

Manual Parsing

When automatic parsing is disabled, the Parse All command is enabled and can be used to invoke the parser manually. All dependent objects which need parsing since you enabled syntax parsing are then considered by the parser.

When you correct and save your sources, the error markers in the Navigator view or in the Natural Navigator view and the entries in the Problems view are not automatically removed. To remove them, you have to invoke the Parse All command once more (or you have to switch on automatic parsing).

To parse dependent objects manually

• From the Project menu, choose Parse All.

  Or:
  Press CTRL+ALT+P.

Unicode and Code Page Support

When a source is downloaded from a Natural server into the Eclipse workspace, the source is always converted from the server encoding to the Eclipse text file encoding UTF-8.

The server encoding of the source is stored in the source header (for further information on the source header, see below).

In the Navigator view or in the Natural Navigator view, you can change the server encoding of the source in the Properties dialog box of the source. The supported ICU encodings depend on the Natural server. See Changing the Object Properties.

When a source is transferred back to a Natural server, it is converted to the server encoding that is defined in the Properties dialog box of the source. When the source contains "unsupported" characters, it cannot be saved on the Natural server and the server returns an error.

In the Natural Server view (on UNIX, Windows and OpenVMS servers only), you can also change the encoding of a Natural object in the Properties dialog box (on the Object Details page). Changing the encoding of an object means that the encoding information which is stored on the server is changed; it does not mean that the content of the object is converted in any way.

For more information, see Unicode and Code Page Support in the Natural documentation for the appropriate platform.

Bidirectional Language Support

Some languages, for example Arabic and Hebrew, are written from right-to-left (RTL), whereas the majority of the languages, for example English and German, are written from left-to-right (LTR). Text which contains both left-to-right and right-to-left characters is called bidirectional text.

In addition to the bidirectional language support of the Eclipse workbench (see the Eclipse online help for further information), NaturalONE offers special bidirectional support which is described in the topics below:

• RTL Visual Order View

• Visual Order Option

• Map Editor and PM=I

• Arabic Shaping

RTL Visual Order View

The RTL Visual Order view is used to support applications that have been originally written for terminals which support inverse (right-to-left) print mode, but no bidirectional data. These applications create the display order of bidirectional data in the application code, that is, the application data is stored in visual order.

The RTL Visual Order view can be used in the following cases:

• With the source editor.

• With the Source page of the map editor, which shows the code for a processing rule.

The selected line in the active editor (either in the source editor or on the Source page of the map editor) is converted from visual to logical format and is displayed in right-to-left screen direction (first text box in the view) and left-to-right screen direction (second text box in the view).

If you want to change the currently selected line in the active editor, you can do this in the RTL Visual Order view. Every change is immediately reflected in the editor.

Visual Order Option

When the Visual order option is selected in the Natural preferences (see Regional Settings > RTL Languages in Setting the Preferences), the application data (that is, Natural sources and data from databases) is assumed to be in visual order. In this case, several editors and tools convert the data from visual order to logical order before displaying the data. When the data is saved, it is converted back to visual order.

Map Editor and PM=I

The settings for bidirectional language support are defined in the Natural preferences. See Map Editor in Setting the Preferences.

Inverse print mode is supported for maps and data fields. The corresponding parameter (PM=I) can be set in the Properties view. See Changing the Properties for the Map in the description of the map editor.

Arabic Shaping

In Arabic text, all characters of a string are normally connected with each other. For this reason, Arabic characters have up to 4 presentation forms: the isolated, the final, the initial and the medial form. The form that will be used depends on the position of the character in the string. For example, the Arabic character "MEEM" has the following forms in Unicode:

U+0645		ARABIC LETTER MEEM
U+FEE1		ARABIC LETTER MEEM ISOLATED FORM
U+FEE2		ARABIC LETTER MEEM FINAL FORM
U+FEE3		ARABIC LETTER MEEM INITIAL FORM
U+FEE4		ARABIC LETTER MEEM MEDIAL FORM

Moreover, some characters are combined to a new form if they appear consecutively in a string. This is called a "ligature". For example, the characters

U+0644		ARABIC LETTER LAM
U+0627		ARABIC LETTER ALEF

have the following combined form:

U+FEFB

ARABIC LIGATURE LAM WITH ALEF ISOLATED FORM

Unicode strings should include only the Arabic characters in the Arabic block (U+0600 through U+06FF) or the Arabic Supplement block (U+0750 through U+077F); it is not recommended to use the presentation forms in regular Arabic text. It is up to the user interface to display the correct shapes of the characters. However, applications which have been originally written on simple terminals often use Arabic presentation forms in the strings.

If data containing characters from the Arabic presentation forms has to be handled in the Eclipse context, it is necessary to unshape the Arabic characters for getting full bidirectional support from Eclipse. "Unshape" means that every Arabic presentation form character is converted to its base character. For example, U+FEE2 (ARABIC LETTER MEEM FINAL FORM) is converted to U+0645 (ARABIC LETTER MEEM).

When the data is transferred back to the original server, it is necessary to shape the Arabic strings again for getting full bidirectional support on the server platform. "Shape" means that every Arabic base character is converted to the appropriate Arabic presentation form. For example, if U+0645 (ARABIC LETTER MEEM) is used as the last character of a string, it is converted to U+FEE2 (ARABIC LETTER MEEM FINAL FORM).

NaturalONE supports Arabic shaping during source transfer. Using the Natural preferences for Arabic shaping (see Regional Settings > RTL Languages in Changing the Project Properties and Regional Settings > RTL Languages in Setting the Preferences), Arabic shaping conversion can be controlled. The unshape operation is performed when sources are downloaded from a server and the shape operation is performed when sources are uploaded to a server.

Notes:

1. It is not guaranteed that a source will be absolutely the same as the original source after performing an unshape/shape operation. The shape operation will always use ligature forms if possible, even if the original source contains the single character forms. Moreover, if the original source contains an "improper" shape (for example, a final form where an initial form is expected), the shape operation will not restore the original character.
2. Sources which contain Arabic strings both in visual left-to-right (LTR) order and in logical order cannot be handled with NaturalONE. NaturalONE assumes that all strings in a source are stored in the same order.

Source Header

A source header is used to maintain some source properties (such as programming mode or code page).

The source header is part of a Natural source. It is removed when the source is transferred to the Natural server and is reinserted when the source is read from the server into the Eclipse workspace. Since the header belongs to the source, it remains in the source when it is stored in the repository of your version control system.

When using a Natural editor in Eclipse, the source header is protected. In this case, it cannot be modified or deleted. The background color for the protected lines which make up the source header can be changed in the Natural preferences. See Syntax Coloring in Setting the Preferences.

Line Numbers

By default, Eclipse has no line number information associated with a source. Line numbers make it almost impossible to version sources in a version control system: each new or removed line would result in a renumbering of the subsequent lines and these lines would be marked as changed. Therefore, NaturalONE strips off the Natural line numbers from the source.

However, it is possible to switch on the display of the Eclipse line numbers (Preferences > General > Editors > Text Editors > Show line numbers). This may be especially useful in the case of an error because the parser indicates the error position by its line number. This may also be useful when executing a Natural application: in the case of an error, the Natural runtime uses the line number to inform the user about the error position.

Eclipse uses an increment of 1 for line numbering. When Natural objects are downloaded to the Eclipse workspace, all line number references in the source code are renumbered accordingly. When the objects are uploaded to the Natural server, the line number references are all changed back to the original increment.

The following patterns are recognized as being valid line number references (where nnnn is a four-digit number):

(nnnn)
(nnnn/
(nnnn,

The source editor supports the line number references.

By default, line number references in constants are not renumbered when you are editing a source. If they are to be renumbered while editing, you have to enable the Renumber line numbers in constants option in the project properties. See Editor in Changing the Project Properties. However, when you are downloading a source using the Add to New Project or Add to Existing Project command from a server where RNCONST is set to ON, the line number references in constants are always renumbered.

During the download, it is possible to replace the line number references with labels. This can be enabled in the Natural preferences. See Natural > Options in Setting the Preferences.