Examples of applications with long-running operations

The following are some overviews of suggested implementation styles when building applications with long-running operations using VA Smalltalk. These examples are intended to show typical ways that applications can be written using VA Smalltalk. Of course, every application is different so developers can use any or all of these techniques, or construct new idioms that are more appropriate to their problem domain. The important point to remember is that, there are no surprises. Every aspect of the polling model is accessible to the application developer. Nothing is done "under the covers."

Example 1: a simple text editor

A simple text editing application is constructed using VA Smalltalk. The application is responsive in all situations except while reading or writing the file that is being edited. To maintain responsiveness in this situation, file reading and writing are moved to a background process. The operations are modified to use a modal "percentage complete" dialog that is updated by the background process using asyncExecInUI:. When the file has been completely read or written, the background process uses a call to syncExecInUI: to close the dialog.

Example 2: a program development environment

A program development environment is constructed that uses a database to store source code. Saving large segments of source code is found to cause a lack of responsiveness because several database accesses are required. To maintain responsiveness, the saving operation is modified to:

•	Disable any menus or buttons that could affect the saving operation

•	Change the cursor to indicate that an operation is "in progress"

•	Generate a background process that first saves the source to the database, and then uses asyncExecInUI: to re-enable the menus and buttons and set the cursor back to normal.

Example 3: a complex drawing editor

A drawing editor is constructed that allows large, complex drawings to be built. The system is responsive in all situations except while updating a display of a large drawing. The update display (refresh) operation is modified as follows:

•	First, it checks the complexity of the drawing (for example, by detecting the total number of primitive graphical objects that it contains) and if it is below a particular threshold, it refreshes the drawing directly.

•	If the drawing is too complex to refresh in the UIProcess, the operation changes the cursor to indicate that a refresh operation is "in progress."

•

Then it generates a background process that draws the diagram, one component at a time, using a background user interface request for each component. After the diagram is redrawn, the application sets the cursor back to its standard shape using a synchronous background user interface request. The application retains a reference to the background process in order to terminate it if the user performs some action that invalidates its usefulness (for example, resizing or closing the window, or using a menu entry to request another refresh or switch to a different drawing).

Notice that in this example, the same code could be used to do the actual refreshing of the drawing, regardless of whether it is being run by the UIProcess or by a background process, because the "ExecInUI" methods can always be called by both background processes and the UIProcess.