The real test of a transitional technology is how well it does on conversions.

The main challenge in converting code written for a character interface into a windows program is that the structure of the programs needs to be different.

There are three different types of program structure available within M programs: block, modular and object oriented (OOP), in ascending order of complexity (and therefore of flexibility).

Most character-based programs are written in block form. They generally have three different blocks which keep repeating: the first block, the user-interaction block, writes out the prompt and reads the response; the second block checks the user's response for syntax and appropriateness, and then either returns to a previous prompt, quits or goes to the third block, which files the data (see figure 3).

figure 3.

These three blocks keep repeating until all the data is collected (figure 4).

figure 4.

The two major variations on the block structure are:

1. Prompt and Syntax blocks repeat until all the data is collected, and then all the filing is done in one block which follows (figure 5);

figure 5.

2. All the prompts are written out first, in a "form" and then all the reads, syntax and filing blocks follow (figure 6).

figure 6.

What all of these block structures have in common is that regardless of when the prompt is written out, each read happens in a linear order. The program determines which question comes next, and the user's only choice is to respond to the computer's next question. This form of interaction is called "modal."

Because of this modal interaction, the read blocks (and often the writes as well) occur every 10-30 lines, with syntax and filing blocks interspersed.

Windows programs tend to be non-modal. The program displays all the prompts (similar to the modal "form" structure) but the user can interact with the widgets in any order. In traditional window solutions, this is handled by porting each syntax block up into its widget in the window, so that each object does its own syntax checking (and sometimes its own filing). In most Windows/M hybrid solutions, this means having some code up in the window, and other subroutines down in the database. This tends to make maintenance more difficult, and the design specification more complex. This type of structure is considered Object Oriented Programming (OOP).

SWIM programs are a half-step between the block and OOP structures: they require a modular structure. Since SWIM keeps all of the code in M, there is no need to move code up to the window, but the block structure needs to be reorganized to accommodate the non-modal interaction allowed by windows.

By cutting and pasting all the prompts into a "windows definition" module, and the syntax and filing blocks into a "RTN" module, a SWIMified routine restructures a CHUI program for GUI, using most of the CHUI code, unchanged.

Because the data returned from the window is in local M variables, the original syntax and filing blocks will need little or no changes. Changing a typical CHUI M program to interact with SWIM requires changing only about 10% of the code.