Enable Runtime Explorer
Rex is a tool for developers that implements the runtime-driven development cycle (see Figure 1). There are three components:

• Runtime Engine: This runs together with the application so that it can be explored in runtime, enabling errors/improvements to be identified and layouts/properties/scripts to be changed as a consequence
• Rex IDE: This allows the developer to review the work performed in runtime and decide how to proceed: view, create reports, or submit to Enable Source Change
• Enable Source Change (ESC): This automatically applies to the source code the runtime changes that are confirmed by the developer using Rex IDE

Runtime Engine
Rex's main panel (see Figure 2) displays the runtime tools (plug-ins) available to the developer together with the controls architecture of the selected window. This information is provided by the runtime engine, which writes the changes made in runtime to a log file that's subsequently analyzed by Rex IDE.

Separating the runtime and design time components makes it possible to analyze the application's behavior on PCs that aren't part of the main development environment. In this way, specific feedback can be obtained from colleagues, test engineers, and technical support. Even power users and graphics designers, with no access to the source code, can propose detailed revisions for review by the developer.

Rex IDE
As mentioned, the plug-ins write to a log file opened by Rex IDE. Each transaction recorded in the log file can be reviewed and processed as appropriate, depending on the plug-in concerned. Possible operations include:

• View: The DWSnapShot plug-in, for example, provides the full state of a DataWindow captured in runtime
• PSR report: The Img Capture plug-in, for example, documents the images captured, together with the related notes, in a report sorted by Window name
• ESC: The PropertyX and Layout plug-ins, for example, send commands to ESC to update the source code to reflect the changes made in runtime (see Figure 3).

Enable Source Change
ESC is a batch command processor that applies the change transactions confirmed by the developer using Rex IDE directly to the application's source code. This component makes it possible to change automatically the properties of a DataWindow object or control and to amend scripts (see Figure 4).

Plug-in Architecture
Rex's plug-in architecture means that new components can be created whenever required for use in runtime and Rex IDE. Indeed, developers can write their own plug-ins and aren't dependent on Enable Development for this. Examples of runtime activity by plug-ins include:

• Analyzing the content of objects: Using BufferX, for example, developers can manipulate DataWindow and DataStore buffers
• Capturing elements for analysis: DWSnapShot, for example, captures the full state of a DataWindow (to reproduce a bug or for testing purposes) so it can be examined at design time
• Capturing elements to be included in reports: Img Capture, for example, captures screenshots for inclusion in a PSR report
• Making changes for application to the source code: PropertyX, for example, displays and changes the properties of objects and DWOs, while ObjectX displays and changes the related scripts

Since Rex's plug-ins work in runtime they have access to all properties of controls and, in general, to the true state of the application. Accordingly, the work done using them is inevitably more accurate than that based on the static view available at design time.

Table 1 shows the runtime tools are currently available.

There's no limit to the number of plug-ins. Developers can write their own, while others are already at the design stage:

• Transaction ObjectX: View the properties of the application's transaction objects, connect to/disconnect from databases, create dynamic DataWindows that can be explored in the same way as any other DataWindow, change or reapply the transaction object to the current DataWindow
• InstanceX: View the properties and instance variables of user-defined classes
• Object Factory: Create new controls in windows
• Help Author: Write portions of help files and associate their contexts to specific objects
• Extension for ObjectX to facilitate script changes Extension for PropertyX to include painters for each property type: Colors, SQL statements, Filters, Sort, Computed fields

The New Development Cycle
Traditional approach
Following the design of classes and the creation of framework structures, the typical development cycle in RAD environments can be summarized as follows:

1. Runtime activity:
   - Analysis of improvements to be made, identification of behavior to revise or rewrite, search for bugs (using the debugger or otherwise)
   - Annotation in a "manual log file" - hard copy or electronic
   
2. Review of proposed changes noted in the manual log file
3. Design time activity:
   - Best-effort correction of the behavior identified at runtime based on the list of activities/changes to be made
4. Return to runtime:
   - Run the application, log-in, open the required windows
   - Repeat the cycle to check on the effect of the changes (OK/KO)

This development cycle is very straightforward, but there are a number of issues: