This document covers the following topics:
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 Project Explorer 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. |
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 (Project Explorer 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 (Project Explorer view or Natural Navigator view). For further information, see the following section:
Creating Natural Objects in Working with Natural Projects in Local Mode.
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 or
command, the normalization is reversed: the
internal data format of the Natural server is then generated from the
DEFINE DATA statement.
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.
Note:
When certain prerequisites are fulfilled, Natural Studio's
dialog editor can be accessed directly from NaturalONE. See
Working with
Dialogs.
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 Project Explorer view or in the Natural Navigator view.
Note:
Syntax parsing of dependent objects can be enabled and
disabled. For further information, see Parsing Dependent
Objects.
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.
Note:
The label decorations for the server problems are controlled by
the preferences under General > Appearance > Label
Decorations. If you do not want to have these label decorations,
just go to the above mentioned preference page and deselect Natural
Compiler Problems.
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 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.
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 Project Explorer 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:
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 command or by setting the corresponding option in the Natural preferences (see Natural > Builder in Setting the Preferences). When you choose the command, the setting in the preferences is adapted accordingly, and vice versa.
When automatic parsing is enabled, a checkmark is shown next to the command.
To enable or disable automatic parsing of dependent
objects
From the menu, choose .
When automatic parsing is disabled, the 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 Project Explorer 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 command once more (or you have to switch on automatic parsing).
To parse dependent objects manually
From the menu, choose .
Or:
Press CTRL+ALT+P.
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).
Caution:
When you edit a source in the Eclipse workspace and this
source has UTF-8 encoding, you can enter any Unicode characters, however, only
characters which are contained in the server encoding can be uploaded to the
server.
In the Project Explorer 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.
Note:
The SRETAIN profile parameter (set on
the Natural server) is not evaluated when uploading a source to a Natural
server. You have to define a suitable project encoding in the Natural
project
properties or a suitable server encoding in the
object
properties of the individual Natural objects. For example, if you
leave the text box for the project encoding blank in the project properties, a
code page will not be assigned to all newly created Natural objects. This is
also true for a temporary project which is created when you edit a source in
the Natural Server view.
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.
Error Messages which are created in/or downloaded to Natural projects in the Eclipse workspace are stored in UTF-8 file encoding. However, the error messages do not contain the original server encoding.
When downloaded from a Natural server, the error message will be converted from the server encoding to UTF-8 and when an error message is uploaded to a Natural server it will be converted from UTF-8 to the server encoding. All characters which are not contained in the server encoding will be lost.
So the runtime environment of your Natural project should be started with the correct encoding.
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:
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.
Note:
This view is not shown by default when you open the
NaturalONE perspective. For information on how to display it, see
Showing a View of the
NaturalONE Perspective.
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.
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.
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.
Important:
With the current version of NaturalONE, support for
Arabic shaping is provided as a preview version. There will be no support for
this preview version. Any feedback from our customers on this new feature is
greatly appreciated. Since support for Arabic shaping is still under
development, a later version of NaturalONE may include substantial changes to
this type of support.
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:
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.
Caution:
When using a non-Natural editor, do not modify or delete the
source header. This may result in compile errors or properties which can no
longer be assigned correctly.
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.
Caution:
If the Natural sources are modified with an editor other
than the source editor, line number references may be destroyed.
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 or
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.
Important:
When the above mentioned option is set in the Natural
preferences, all valid line numbers (as described above) will be replaced with
labels. It will not be checked whether the result is valid Natural syntax.
Therefore, it is up to you to check the result of the replacement.