Cursor Positioning

The structure editor has to decide where to position the cursor after processing. Some ProcScript statements and structure editor functions change the active path.

ProcScript Statements

Many ProcScript statements cause the cursor to move. The store statement, for example, causes all outstanding data validation to take place, and restarts the active path. This means that the position of the cursor can change after store. A setocc statement usually makes a different occurrence active, which also results in a new cursor position. Setting $prompt also forces a new cursor position.

The logic used to determine the new position of the cursor varies from statement to statement. For example, restarting the active path after a store statement means that the cursor returns to the first promptable field; in character mode, this is only valid if the exec operation of the form contains an edit/nowander statement, otherwise the cursor returns to the top left corner of the form.

Effect of the store statement on the active path

Graphical content.

If the edit statement in the exec operation specifies a field name, as shown in the figure, the cursor is placed in the field of the first painted occurrence containing that field. In character mode, if there is no field name , the cursor returns to the top left corner of the form.

Here are many rules and many possible results. This information is provided here by way of an example only. The effect of individual ProcScript statements on the cursor position can vary. For more information, see ProcScript: Statements.

Navigation Functions for Fields

The ^FIELD function moves the cursor to another field. The direction is determined by the current direction mode; it is ^NEXT by default.

The ^NEXT_FIELD function takes you to the next field as scanned from left to right and top to bottom; the ^PREV_FIELD function takes you to the previous field as scanned from right to left and bottom to top. The behavior is affected if:

  • There is ProcScript in the next or previous trigger.
  • The cursor is not in a field when ^FIELD occurs (character mode only).
  • There is more than one painted occurrence of the current entity.
  • There are inner entities and the direction mode is Previous.

The ^NEXT_FIELD function activates the next trigger if this is a valid action in the current context, and if that trigger contains ProcScript. The ^PREV_FIELD function activates the previous trigger if this is a valid action in the current context, and if that trigger contains ProcScript.

ProcScript in these triggers can place the cursor in a particular field (by setting $prompt), or cause entirely different processing to take place.

If a cursor is in white space and not in a field, it is not immediately obvious where the structure editor should place the cursor, if the user issues a ^FIELD function. For example, when the cursor is not in a field and the user issues a request to the structure editor for ^NEXT_FIELD, the structure editor carries out a field scan. This is a simple search from left to right and top to bottom. The first field encountered in this scan becomes the next field.

^NEXT_FIELD when the cursor is in white space (character mode only)

Graphical content.

If such a scan reports no next field, the cursor does not move and the terminal beeps.

^NEXT_FIELD and ^PREV_FIELD do not take you to the next or previous occurrence of the same entity. Therefore, the field scan ignores any fields in any other painted occurrences of the entity you are currently in. Instead, ^NEXT_FIELD places the cursor in the first field of the first painted occurrence of the next entity found on the left to right, top to bottom search. If there is no next field or if there is no ProcScript in the <Next Field> trigger of the current field, the cursor does not move.

Field scan with ^NEXT_FIELD is not the same as ^NEXT_OCC

Graphical content.

^PREV_FIELD places the cursor in the last field of the first painted occurrence of the next outer entity found on the right to left, bottom to top search. If there is no previous field, or if there is no ProcScript in the next or previous trigger of the current field, the cursor does not move. The emphasis is on the ‘next outer entity’ with ^PREV_FIELD, because this function misses out inner entities altogether, as shown in the figure. The scan only works from inner to outer.

Field scan with ^PREV_FIELD ignores inner entities

Graphical content.

Moving From Occurrence to Occurrence

The ^OCCURRENCE function takes you from one occurrence to another within the current entity. The default direction is Next, but you can combine ^OCCURRENCE with ^NEXT or ^PREVIOUS to explicitly determine (change) the direction. You can also use the ^FIRST and ^LAST functions with ^OCCURRENCE, to take you to the first or last occurrence of an entity, respectively.

Note:  ^OCCURRENCE does not take you to another entity.

You can also use the cursor keys in character mode to move to another occurrence, although these do not cause the structure editor to activate the getFocus trigger implicitly for the new occurrence.

The ^OCCURRENCE function causes the structure editor to scroll occurrences into view, if they are ‘invisible’ but present in the form (or hitlist). As shown in the figure, ^NEXT_OCC would cause the unseen occurrences to scroll up to show the occurrence containing the values Number3, Name3, and Notes3. ^PREV_OCC would scroll down and display the occurrence containing Number1.

^NEXT_OCC or ^PREV_OCC with one painted occurrence

Graphical content.

If more than one occurrence is visible on the screen at the same time, the ^NEXT_OCC function moves the cursor and not the occurrence, provided that the next occurrence is available in the form and is visible. If there is another occurrence that is not visible, Uniface scrolls it into view and places the cursor on it. The occurrence where the cursor ends now has the focus, so the structure editor activates the getFocus trigger.