Guesswork About the Effect of Work in Design Time
All changes have to be carefully checked in runtime. Consider, for example, the properties that are changed dynamically, the size of the DataWindow controls (number of rows displayed), the alignment of controls present in several tab pages (difficult, since they aren't all visible simultaneously), or multiple DataWindows, SQL statements with dynamic where conditions.

Trial and Error
The iterations between design time and runtime contain a strong element of trial and error, with each cycle taking time and possibly introducing new errors. This process is often extremely tiresome and many applications fail to achieve the quality standards desired by end users, especially when it comes to the UI or error messages. Special skills needed at the review stage

The review of certain parts of the application (UI, user terminology and messages, interaction between windows) often involves getting input from colleagues, graphic designers, clients (the boss...). However, design time activities must be carried out in the development environment, which requires:

• Access to all or some of the current source code
• Availability of the development environment
• Knowledge of the underlying applications logic

As a consequence, those with demands, suggestions, or help to offer must usually work directly alongside the developer, who attempts to change the source code directly or, more likely, takes notes to be followed up later.

Runtime-Driven Approach
The development cycle using Rex is somewhat different (see Figure 5):

1. Runtime activity (by developer, colleagues, test engineers, end users...):
   - Discover, understand (similar to the traditional approach, but with sharper tools)
   - Use available plug-ins to explore specific aspects (status of buffers, contents of Data-Stores, dynamic SQL statements)
   - Make changes (possibly simulating the effects in runtime)
   - Write to the log file, which can be sent to multiple recipients for review
   
2. Review of proposed changes in Rex IDE, accompanied by notes and precise indications about how they should be implemented
3. Design time activity:
   - Send the changes to ESC, which changes the source code automatically, producing the desired result the first time without iterations
   - Create reports (to-do lists) for changes that can't be implemented automatically (e.g., notes added by a test engineer about how to reproduce an error)
   
4. Return to runtime:
   - Run the application to look for new changes

Comparison/Combination of Approaches
The traditional approach is heavily iterative, while (as the name suggests) adoption of the runtime-driven approach implemented by Rex involves predominantly runtime activities since, where appropriate, the application's source code is simply updated automatically. The security and protection aspects are covered in various ways, as discussed below.

The new "right first time" runtime-driven development cycle introduces a higher level of precision and assists productivity by eliminating trial and error. In addition, certain activities that used to be an overwhelming challenge (aligning controls in multiple tab pages...) are a simple matter when working directly in runtime.

Of course, the runtime-driven approach can't fully replace the traditional approach. You still have to work on an existing application, since (for the moment!) it's not possible to create a new application from scratch directly at runtime. However, when it comes to "tuning" the application, runtime tools are more powerful and precise.

Runtime-Driven Approach: Collaboration
As mentioned, the runtime-driven approach facilitates collaboration (involving other developers, graphic designers, power users) since they don't have to physically sit down alongside the developer to do a review. They can simply submit a log file for consideration.

Conversely, it's possible to work with them on the current source code, since the ESC transactions can be reapplied at any time. This means that development work can continue while the review process is still underway, without having to worry about comparing versions and making manual alignments subsequently.

Enable Source Change
All the Rex components are important in the runtime-driven development cycle. This said the key element of this approach is represented by Enable Source Change.

ESC updates the source code by processing change transactions that can be cancelled/repeated. The Rex IDE is used to manage ESC, which, if desired, can also process command scripts. Three types of source code changes are currently possible:

1. The value of a property of a control
2. The value and/or expression of a property of a DWO
3. The script of a method (event, function, sub-routine)

   Other change types are already planned, such as:
   

4. Change Ancestor, e.g., create a new ancestor class for existing objects
5. Substitute method call, e.g., replace system functions with user-defined functions (messagebox -> of_messagebox)
6. Add to script, e.g., add a specific command at the start or end of a script