Using PowerBuilder 3.0

Author: Alan C. Dube

Date: 8/17/95

Using PowerBuilder 3.0 for Windows Application Development

Introduction

Background

Advances in personal computer (PC), local area network (LAN), and microcomputer-based server platforms have dramatically changed the way computers are used and programmed for business applications. The market success of Microsoft Windows has transformed the standard PC workstation from a character-based to a graphical user interface (GUI) environment, freeing users from the limitations of the DOS operating system and allowing them to easily launch and use many sophisticated applications simultaneously. PCs and servers operating on LANs have propagated the concepts of distributed and client-server computing by removing sole reliance upon the expensive mainframe/terminal platform for all computing tasks, empowering the individual user and business unit in the process.

Information systems (IS) departments are coping with this new frontier by transitioning away from COBOL (Common Business Oriented Language -- the primary development language of the mainframe) to those client-server languages and construction tools which best meet their needs and objectives (Baum, 1994).

Choosing the correct tool remains a difficult process. Like COBOL on the mainframe, the C programming language evolved as the dominant engine for developing GUI systems in a client-server environment (Mattison, 1994). However, the use of C poses immense challenges to traditional IS organizations that want and need to migrate to a client-server platform: C is difficult to learn and master and requires a relatively large amount of code for GUI applications. An easier, more intuitive development platform is needed if client-server, GUI applications are to be written and distributed in rapid and efficient manner.

Purpose

For many businesses, PowerBuilder (from the Powersoft Corporation) appears to be the answer. This paper presents an in- depth report and evaluation on using PowerBuilder 3.0 for Windows application development from a human-computer interaction (HCI) perspective, first providing a general overview of what PowerBuilder is and the challenge involved with using it, then discussing some current literature relevant to GUI design and PowerBuilder in general. The paper then demonstrates PowerBuilder's capabilities by documenting how an actual application was created: The GUI construction and coding process is examined in detail, and conclusions drawn on PowerBuilder's development environment, tools, and methodology. In closing, the paper discusses Powersoft's approach to object orientation, technical support, strategic partnerships with other vendors, and the new features and improvements found in release 4.0 of PowerBuilder.

What is PowerBuilder?

The PowerBuilder User's Guide (1993) states that:

PowerBuilder is a graphical PC-based client/server applications development environment. Using PowerBuilder, you can easily develop powerful Microsoft Windows applications that access your server databases. PowerBuilder provides all the tools you need to build industrial-strength applications, such as order entry, accounting, and manufacturing systems (p. 4).

PowerBuilder uses a practical approach to object orientation that allows developers to quickly make the transition to GUI development without the knowledge of C or Windows programming internals. PowerBuilder contains its own scripting language, called PowerScript, that is BASIC-like and supports inheritance and encapsulation of processing logic within objects. PowerScript is used to relate GUI objects in an application, such as a window, push button, or scroll box, using object "events": a mouse click, key press, or an object receiving user focus in some other fashion. PowerBuilder provides strong support for object reusability by allowing for the creation of custom user objects and shared libraries.

PowerBuilder supports IS development teams in building graphical business systems that need to access one or more relational data base management systems (DBMS) using Structured Query Language (SQL). PowerBuilder's DBMS capabilities provide excellent integration to many back-end database systems (such as Sybase, Oracle, DB2, and Ingress) and fully exploit the features of each data base. PowerBuilder's unique graphical approach to development supports team projects through a common library manager and central design repository. All the various components of an application, including windows, menus, business rules, data base design, and reporting, can be developed entirely within PowerBuilder -- thus speeding up the development process.

The Challenge of Using PowerBuilder

PowerBuilder may be the answer for Windows and client-server development, but it also presents IS organizations with a broader concern: Although PowerBuilder gives developers increased speed, ease of use, and flexibility in designing and implementing direct- manipulation controls, they can be misused. PowerBuilder and GUI developers, more so than their character-based counterparts of the past, need to concentrate intensely on the HCI factors of the applications they develop. The Windows and direct-manipulation controls must be designed and integrated into the PowerBuilder application properly, and from a user perspective, in order for the application to be successful.

Literature Review

The shift to the graphical desktop has created many challenges for both the user and developer, as indicated by the growing body of literature in the field. Although recent attempts have been made by the major software vendors to standardize graphical design methodologies, as discussed by International Business Machines (IBM) in the Common User Access Guidelines (1992), and Microsoft (1992) in the Windows Application Design Guide, there is still much room left for interpretation and debate. Leavens (1994) notes that the rules for GUI design can be confusing, and stresses the importance of consistency to create an intuitive user interface. Galitz (1994) observes that application developers need to resist the temptation of offering the user too many options in order to avoid creating applications that are cluttered, unfriendly, and functionally useless. Powersoft (1993), in the PowerBuilder User's Guide, defines its interpretation of these emerging standards and philosophies while adequately documenting the functionality, depth, and breadth of the PowerBuilder product.

Marcus, Smilonich, and Thompson, in their book The Cross-GUI Handbook for Mulitplatform User Interface Design, (1995) have addressed the issue of designing GUI applications that must operate on multiple computer platforms (e.g. Windows, OS/2, Macintosh, OSF/Motif). They note that even though the platforms share many similarities, there are at times subtle differences that the developer must be aware of to ensure the consistency of any given application from one platform to another. Caffaso (1995) notes that this is especially important for the continued success of PowerBuilder, as Powersoft plans to deliver the product for the Macintosh and Sun's Solaris platforms in 1995 when beta testing is complete.

Much of the recent research and literature on GUI design stems from classical findings made and advice given by earlier authors, such as Shneiderman (1992), and Cox & Walker (1993). Mullet and Sano (1995) have authored a particularly interesting and highly illustrated work on GUI design entitled Designing Visual Interfaces: Communication Oriented Techniques. In it, Mullet and Sano describe the fundamental techniques that can be used to enhance the visual quality of GUIs, data displays, and multimedia productions from the perspective of communication- oriented graphic design, industrial design, and architecture.

PowerBuilder claims to be an object-oriented development environment. Khoshafian and Abnous (1990) offer a clarification of the basic concepts associated with object orientation in their comprehensive work entitled Object Orientation: Concepts, Languages, Databases, User Interfaces. They define technical jargon (such as inheritance) in understandable terms and relate the principles to programming style and development environments.

As a new and exciting tool, PowerBuilder has generated a lot of attention in the IS trade press. Mattison (1994) offers an interesting survey and review of the more popular development environments in use today. Baum (1994) explains how a major corporation used PowerBuilder to rapidly transition their information processing off of the mainframe to a client-server, GUI architecture.

PowerBuilder's market success is not without its growth pains. There have been some architectural and performance problems associated with the product (Kay, 1995). Powersoft has had a hard time keeping up with customer demand for technical support (Damore, 1994), but has made improvements in service as new releases and upgrades of the software reach the GUI programming public (Gryphon, 1995).

Methodology

Define the Database

The sample application that was created using PowerBuilder is a traditional human-resource (HR) system: an employee and department database which stores and manipulates information such as name, address, salary, and benefits selections. PowerBuilder comes with a single-user version of the Watcom SQL Database Engine, which was used for this application, as a complimentary part of its development environment.

The first step in the process was to create the database and define its structure (i.e., entities and attributes) using the database painter. PowerBuilder provides support for many DBMSs and addresses the unique functionality and issues particular to them in the DBMS interface manual. Use of the database painter from PowerBuilder to create and define a database is optional; The database may already be present on the target DBMS that the application is to reference. The database painter merely provides a tool to manipulate data and manage objects (e.g., tables, views, and indexes) and connections to the host DBMS, provided that the developer has the proper knowledge and authorization to do so. The database painter is also used to define extended attributes for a table: those properties, such as format, edit, and validation rules, that are PowerBuilder specific and are used to enhance the definition of a column (Powersoft, 1993).

The database painter was invoked by clicking on the database icon, which is present on both the PowerPanel and PowerBar (see Figure 1). The developer may choose to use either the PowerPanel (the icon/toolkit metaphor used in version 2.0 of the product) or the PowerBar (the preferred method -- an icon-based toolbar that replaced the PowerPanel) to guide the application construction process. The PowerBar is customizable as to its screen location and iconic content; the PowerPanel is not. A customizable PainterBar with its functional icons then appeared within the database painter (on the left side of the screen, as it did by default for all of PowerBuilder's construction tools), to guide the database design. Figure 2 illustrates the human resource database, showing the employee and department table attributes, and the primary (P) and foreign (F) key definitions.

Overall, the database painter was intuitive and easy to use. The painter's icons were used effectively to portray the semantics of database management, and the graphical metaphor used to display the object and entity relationships adhered to Mullet and Sano's (1995) principle of cohesiveness: the common visual characteristics that allow each image to be perceived as part of a larger program, even as it is distinguished from the other members of the ensemble (p. 182).

Define the Application

The next step in the development process was to define the application object to PowerBuilder by clicking on the application icon on the PowerBar. The File...New menu command was then used to create a new PowerBuilder Library (.PBL) file, named HRDB.PBL in this case. The .PBL file is used by PowerBuilder to store an application's objects, references, and the "glue" that links them all together -- PowerScript code. The application painter is also used to identify an application's icon, default fonts, and library search path. Libraries can be shared across multiple PowerBuilder applications -- allowing for object reusability -- hence the need to specify a search path. The application painter is also the point from which a completed application can be compiled and linked to a Windows executable (.EXE) for product distribution.

A key feature of the application painter is its hiearchial object display, which is similar to the Windows File Manager metaphor of expanding and collapsing directory branches by double clicking on them. Figure 3 illustrates how an application and its referenced objects are graphically linked together. Additionally, each of the painters for the given object type can be directly accessed by first clicking on the object icon, and then pressing the enter key. Shneiderman (1992) observes that this type of direct-manipulation design has several beneficial attributes: knowledgeable intermittent users can retain operational concepts; error messages are rarely needed; and users can immediately see if their actions are furthering their goals or can change the direction of their activity if it is counterproductive.

PowerBuilder, as with most GUI development environments and languages, uses event-driven programming vs. linear programming. Leavens (1994) observes that a linear program (e.g., a COBOL routine) has a direct and active linear flow of control through the program, allowing only certain things to be accomplished at certain times. Linear programs are not well suited to interacting with users in all forms, and grow exponentially in size when actions such as key strokes, mouse movements, and window operations need to be explicitly coded for. In contrast, event-driven programs are passive by nature, ready at any time to process any sort of event when it occurs. The act of using a Windows application triggers a series of events, and PowerBuilder was designed to allow the developer to intercept the events at the object level and code actions that respond appropriately.

The application painter is the first point from which PowerScript, PowerBuilder's BASIC-like coding construct, was entered using the PowerScript editor (see Figure 4) to link the application object with its underlying objects. PowerScript provides a rich assortment of built-in functions which reinforce the concept of event-driven programming: There is a function to open a window, a function to close a window, a function to enable a button, a function to retrieve data, and so on (Powersoft, 1993). The PowerScript statements, and any functions referenced by them, are executed when the object's event (to which the statements are linked) is triggered. The PowerScript statements are linked to an event by selecting the event in the PowerScript editor, then entering and saving the code (a document icon will then appear next to the event label, indicating there is PowerScript associated with it). The PowerScript code that was linked to the Open event of the human resource application object appears below:

//Set the pointer

SetPointer (HourGlass!)

//Set the sqlca transaction object attributes

sqlca.DBMS ="ODBC"

sqlca.database ="PowerBuilder Demo DB"

sqlca.userid ="dba"

sqlca.dbpass ="sql"

//Connect to the database

Connect;

//Check the result, exit if unsuccessful

if sqlca.sqlcode <> 0 then

MessageBox ("Sorry! Cannot Connect to Database",

sqlca.sqlerrtext)

return

end if

//Open the next window

Open (w_eis)

The first statement used the SetPointer function to change the default Window pointer to the hourglass. Notice that comments were entered at various points in the script by using the "//" characters to define the commented lines. The next series of statements, indicated by the "sqlca" notation, defined the transaction object. PowerScript uses object.attribute notation to manipulate object values. The "sqlca" transaction object, a PowerBuilder default, is the "communication area" used to define the connection parameters referenced when connecting to and communicating with the host database. Here the system type, database name, user id, and password were specified. The Connect statement was issued next -- this triggered the actual connection to the database. The next series of statements checked to see if the connection was successful, using the MessageBox function and quitting the application if it was not. Finally, if the connection to the database was successful, the Open function then opened the window object named w_eis. It is important to note that the window object w_eis cannot be referenced here until it is first created and saved using the window painter.

In remarkably few lines of PowerScript code, a connection to the database was made and the first window of the application displayed. This type of construct is what makes PowerBuilder easy to use. The hardest part about learning PowerBuilder is to understand what events can occur for an object and when they are triggered, so that the proper PowerScript code can be entered and executed for an event in the expected sequence. The developer needs to rely heavily on the documentation and application examples provided with PowerBuilder at first to understand the sequence of events.

Define and Link the Objects and Controls

The window object.

Now that the application object was defined, the next steps were to construct the window objects using the window painter, and link the objects using PowerScript. The window painter was invoked by clicking on the window icon on the PowerBar (see Figure 5). The window w_eis, referenced in the Open event of the application object, was the first one defined. A subsequent window (w_empl_detail) used for the maintenance of employee detail data and called from w_eis was defined next.

PowerBuilder controls (e.g., check boxes, command buttons, radio buttons, static text, data windows, and single or multi- line edits) can be placed on the window object using the PainterBar to facilitate navigation within the application, prompt the user for information, or display data. Their attributes can be set at definition or during runtime by referring to their control.attribute values in the PowerScript. PowerScript code can be linked to events that occur for the window object itself, as well as those triggered at the control level.

The PowerScript code for the Open event of w_eis was:

// Use SetTransObject so each of the two datawindows in w_eis and

// the datawindow in w_empl_detail require only one connect

SetTransObject(dw_dept_list,sqlca)

SetTransObject(dw_emp_list,sqlca)

// Hide the employee datawindow and its shadow initially.

Hide(dw_emp_list)

Retrieve(dw_dept_list)

The SetTransObject function binds the data source specified in the data window controls dw_dept_list and dw_emp_list, using the sqlca transaction object parameters that were initially set in the open event of the application. A detailed discussion of the data window control follows in the next section. The Hide function removes the data window control dw_emp_list from view. The Retrieve function retrieves the data set specified for the data window control dw_dept_list. Notice that PowerBuilder urges the developer to use a consistent naming convention when referring to objects and controls: "w_" for a window object, "dw_" for a data window control, "cb_" for a command button, etc.

The PowerScript code for the Clicked event of the command- button control cb_new:

Hide (parent)

open(w_empl_detail)

Init_dw (w_empl_detail, 0, deptnum, mgrid)

hides the window w_eis, opens the window w_empl_detail, and calls the function Init_dw, passing several arguments. Init_dw, triggered at the Open event of window w_empl_detail, is a user- defined window function:

int i, dept_value

string dept_name

DECLARE dept_cursor CURSOR FOR

SELECT department.dept_id, dept_name

FROM department ;

SetTransObject(dw_empl,sqlca)

// If it's a new employee, Insert a new row as an initialized

// template. Set the values for department & manager ID from the

// main window and protect them (set tab order to zero. Allow

// entry of employee ID. If it's an existing employee, then

// retrieve - passing the argument set in the global from the

// initial window, w_eis.

if empid_parm = 0 then

new_employee = true

cb_delete.enabled = FALSE

dw_empl.SetTabOrder(1,5) // Unprotect employee ID

dw_empl.SetTabOrder(5,0) // Protect department ID

dw_empl.SetTabOrder(2,0) // Protect manager ID

dw_empl.InsertRow(0)

dw_empl.SetItem (1,5,deptid_parm) // Set Department ID

dw_empl.SetItem (1,2,mgrid_parm) // Set Manager ID

else

dw_empl.Retrieve(empid_parm)

end if

// So far, nothing has been changed or updated.

changed_flag = FALSE

update_flag = FALSE

Show (this)

The function illustrates some concepts already covered and introduces some new ones: the ability to declare variables and their data types, to code SQL statements within the PowerScript, and to specify the display state of objects and controls. Variables can be global (exists for the duration of the application), local (exists only for the duration of the event in which they were declared), or shared (exists while the object is in memory).

The Clicked event for the control cb_close on the window objects w_eis and w_empl_detail executes the function Close(parent), which simply triggers the Close event for the parent object to which the command button is linked. The Clicked event for the control cb_apply on the window w_empl_detail executes the following script:

// Update the database and remember that we updated, so main

// window will re-retrieve employee list to reflect changes.

// Don't update if nothing has been entered

if new_employee then

if changed_flag = FALSE then

MessageBox ("Sorry!", &

"You can't update a new employee without changing something.")

return

end if

end if

The Clicked event for the command button cb_delete triggers:

int ret

// Ask if it's ok to delete

ret = MessageBox ("Employee Information System", &

"OK To Delete Employee?", &

Exclamation!,YesNo!)

// Delete only if it's ok. Remember that an update has occured so

// w_eis can refresh the employee list (

if ret = 1 then

DeleteRow (dw_empl,0)

Update (dw_empl)

deleted_flag = true

update_flag = true

Close (parent)

end if

As the window is the main form of interface between a user and a PowerBuilder application, the importance of conforming to Microsoft's guidelines for window and object functionality, which were published in the Application Design Guide (1992), can not be overstated. The window painter contains all the tools necessary to create impressive and functional windows, allowing the developer to specify and define a variety window attributes (e.g., color, title bar, minimize or maximize boxes, scroll boxes, and modal behavior). However, the painter does not force good design methodology; this must be learned through careful study of human factors and development experience.

The PowerScript code examples help to illustrate just how "powerful" the language and functionality contained within it can be. PowerScript and the window painter are the core components needed to build a PowerBuilder application. However, a major reason why PowerBuilder has gained market share over its competitors, such as ObjectView, SQLWindows, and Visual Basic (Mattison, 1994) is because it has the ability to create and associate the reusable data window object to a window object via the data window control.

The data window object.

Applications are built around data. Data window objects are used to display and manipulate data, and are defined using the data window painter (see Figure 6). Three data window objects were constructed for the Human Resource Database (HRDB) application: d_dept, d_emplist, and d_empl_f_arg. The objects were associated with the data window controls dw_dept_list (on window w_eis), dw_emp_list (also on window w_eis), and dw_empl (on window w_empl_detail) respectively.

Data window objects can present data to the user in several different formats: crosstab, freeform, graphs, labels, and tabular. The window w_eis shows an example of tabular data window objects. The window w_empl_detail displays an example of a free-form data window object. Data window objects can also automatically format the display of data at the field level using display formats and edit styles, and can check the input of data using data validation rules.

The data source for the data window objects was defined using a graphical link to the host DBMS in much the same fashion as the table objects appeared in the database painter. The SQL statement that drives the retrieval of the data was fashioned by simply clicking on the fields for the table(s) that were to be included in the result set. Where clauses and sorting parameters for the SQL statement were specified when appropriate. Where- clause conditions are passed as arguments when retrieving the data window. Data window attributes, like window and control attributes, can be specified at design and modified during runtime.

Below is the PowerScript code for the Clicked event of the dw_dept_list control:

int row

// get clicked row number, deselect old one, select new one

row = GetClickedRow(dw_dept_list)

if row > 0 then

SelectRow (dw_dept_list,0,false)

SelectRow (dw_dept_list,row,true)

// Get deptnum of selected row; make available the dept_id and

// manager id available to w_empl_detail as globals

deptnum = GetItemNumber(dw_dept_list, row, 1)

mgrid = GetItemNumber(dw_dept_list, row, 3)

Retrieve(dw_emp_list,deptnum)

Show(dw_emp_list)

cb_new.enabled = true

end if

The GetClickedRow function determines on what row in the data window the user clicks. If the row is valid, then it is highlighted using the SelectRow function. The department number and manager id values are then extracted from the row using the GetItemNumber function, with the department number then passed as an argument to the Retrieve function for the data window control dw_emp_list. When the user clicks on the window dw_emp_list, the following PowerScript code is executed:

int row

// Identify & hilight the newly selected row, deselect the old

// one

row = getclickedrow(dw_emp_list)

if row > 0 then

SelectRow (dw_emp_list,0,false)

SelectRow (dw_emp_list,row,true)

// Get the employee number and store it in a global for use by

// the employee detail window

Hide (parent)

Open(w_empl_detail)

Init_DW (w_empl_detail, GetItemNumber(dw_emp_list,row,1), &

deptnum, mgrid)

end if

As previously stated, the data window object is by far and away the reason for PowerBuilder's success. The data window object allows developers to quickly create data queries and format them into usable controls. More importantly, the data window objects can be reused within the same application, and across other applications if kept within a common library.

Additional Painters

PowerBuilder contains additional painters to aid the developer in the application definition and testing process. Although most of the following painters were not directly used in the development of the HRDB application, it is worthy to note their functionality and how they contribute to the richness of the PowerBuilder environment.

The menu painter.

Menus in the Windows environment are lists of commands or options that a user can select in the currently active window. The commands usually appear in a menu bar below the window title bar and are grouped according to their operations (e.g., Open and Save under the File option). Menus can be created and linked to a window object in PowerBuilder by using the menu painter. Menu objects have attributes much the same as window objects, and can have scripts linked to the different menu choices.

The structure painter.

A structure is a collection of one or more related variables of the same data type, grouped under a single name. Structures allow reference to a related entity as a unit. Declaration of a structure within PowerBuilder is accomplished by the structure painter. Declaring a structure is essentially the same as defining a new data type, which can then be used in scripts and user-defined functions. Variables in the structure are treated the same way as attributes for an object, using structure.variable notation.

The query painter.

The query painter allows the developer to code SQL statements and save them for future reference. The query can then be submitted using the query painter, or incorporated into a data window as a data source. As most query development takes place in the data window painter using select SQL criteria, the usefulness of the query painter is limited to creating only those "boilerplate" queries which are repeatedly executed.

The function painter.

Even though the PowerScript language has many built-in functions, there are times when the developer needs to code the same process repeatedly. Such code is a candidate for a user- defined function, and user-defined functions are created in PowerBuilder using the function painter. Once defined, the function may be called in the same way that PowerScript functions are.

The library painter.

The library painter allows the developer to scan the contents of and organize library (.PBL) files using a File Manager metaphor (see Figure 7). It is up to the developer or development team to decide whether or not to store all of an application's objects in one library, or to store them across several libraries (i.e., a library for data window objects, a library for window objects, etc.). Powersoft recommends storing frequently used objects in a common library that can be referenced by all applications, since a PowerBuilder application can have multiple libraries specified in its search path (Powersoft, 1993). This type of library organization facilitates the concept of team development. Additionally, libraries can be checked out, thus preventing multiple developers from modifying a library entry at the same time.

The user-object painter.

A major feature of object-oriented programming is reusability: the capability of defining an object once, then reusing it multiple times within an application with little or no additional work. IBM used this design methodology in creating its OS/2 operating system (1992), and PowerBuilder uses it for the data window object. The user object painter can be used within PowerBuilder to create custom objects not otherwise available, or those which, like functions, are used repeatedly within an application. User objects are also used within PowerBuilder to reference Visual Basic (VBX) controls, and controls from objects in the underlying Windows system (often referred to as a DLL, or Dynamic Link Library).

The debug painter.

After objects and scripts within an application are saved (and automatically compiled), the application can be run from within the PowerBuilder environment. The application then responds to user interaction and runs until the user ends it, or an application runtime error occurs. All programming tools need the ability to debug an application, and a graphical tool like PowerBuilder is no exception. The debug painter (see Figure 8) allows the developer to insert breakpoints (stops) in scripts and functions, single step through code, and display the contents of variables to locate logic errors and mistakes that result in runtime errors (Powersoft, 1993).

Results

Figure 9 shows the finished HRDB application screens. The user first sees the HRDB screen (w_eis) when the application is invoked, and then is prompted to click on and highlight a department entry in the department data window (dw_dept) for a list of employees. The employee list for the related department is then displayed in the employee data window (dw_emp_list). At this point the user can add a new employee (cb_new), click on the employee data window to view the details of an existing entry, or close the application (cb_close). The HRDB screen becomes hidden and the Employee Details screen (w_empl_detail) appears, along with the detail information (dw_empl), if the user decides to edit an existing record. The same screen would appear blank, except for some default field values, if a new employee were to be added. The user then has the option of applying the changes (cb_apply -- for an employee add or change), deleting the record (cb_delete -- only if the employee exists), or closing the window. Any change made on this window is propagated back to the HRDB screen accordingly.

As previously stated, PowerBuilder gives a developer the tools to create Windows applications, but can only do so much to enforce GUI design standards and good application design. The HRDB application was a relatively simple one, and was kept simple by design. However, even simple Windows applications can be designed incorrectly. Missing from the application is a menu system. Menus are especially critical to Windows applications when the windows themselves can be resized, thus obscuring any command buttons used for data input or navigation. At the very least, menus should be made available for those who feel more comfortable using them, or just having the option to use them.

Other than the menu option, the HRDB application did conform for the most part to published standards and good design practices. The command button terminology, especially the use of the "Apply" term, conforms to IBM's CUA guidelines (IBM, 1992). The command buttons, as suggested by Galitz (1994), are wide enough to accomodate the longest label, are consistent in size, and are aligned horizontally in the lower part of the window. The Employee Details screen makes effective use of drop-down list boxes, radio buttons, and check boxes. Its layout is pleasing to the eye and flows nicely. The single-click, point-selection approach, incorporated on the data window controls for the w_eis window, is a simple and effective way to execute a drill-down metaphor. This technique travels well across platforms, as it is common across several GUIs (Marcus, et al., 1995).

Deploying the Application

Once the application has been tested and debugged, it can be deployed to the end user. The first step in this process is to use the application painter to create a Windows executable (.EXE) from the library file (.PBL). The .EXE, any additional resources (such as bitmap and icon files) and the Database Development and Deployment Kit (DDK -- those PowerBuilder DLLs called when the .EXE file executes) should then be copied to the user's PC. The DDK is included with PowerBuilder, and can be distributed royalty free to the user. For performance reasons, it is best to copy and execute the files to a local hard drive rather than a networked one.

Conclusions

There is no doubt that PowerBuilder is a strong and intuitive development environment for creating powerful Windows client-server applications, as illustrated by the construction of the HRDB application. It's object-oriented approach is logical and understandable. The development environment was created by developers with developers in mind: it is highly customizable, and uses icons effectively to convey action and building methodologies. The construction process is straightforward, and all the tools necessary to build and test impressive applications are included. The PowerScript language is easy to learn and operate, and although the sheer number of functions and events available within PowerBuilder are daunting, they are generally easy to understand and invoke. PowerBuilder applications can be built rapidly, thus facilitating the prototyping process. Prototyping is important, as noted by Cox and Walker (1993), because it is often used with usability testing to develop applications from a user-centric point of view. PowerBuilder is also a fairly open product, allowing the developer to utilize Microsoft objects, external DLLs and objects, and add on products from third party vendors. PowerBuilder remains the platform of choice for transitioning traditional linear programmers to a GUI environment.

PowerBuilder is not without its weaknesses, one of which is certainly cost. At a list price of $3,295 (Gryphon, 1995) it is not cheap. Microsoft's Visual Basic is increasing in functionality with every release, and is available at a fraction of PowerBuilder's cost. PowerBuilder's ease of use is also viewed as it's downfall: performance is sacrificed because of all the "overhead" code necessary to make the development environment user friendly.

Additional Considerations

Object orientation.

Object orientation (Khoshafian and Abnous, 1990) can be loosely described as the "software modeling and development (engineering) disciplines that make it easy to construct complex systems from individual components" (p. 6). By this definition, PowerBuilder does an excellent job adhering to the concept of object orientation by breaking down Windows components into objects (via the various painters), and allowing the developer to manipulate the characteristics of those objects. PowerBuilder also supports the concept of inheritance -- the ability of one object to pass on its attributes to a second object (Kay, 1995)-- by allowing a parent window object to be inherited by a child window object at runtime. In this way, standard application screens or templates, such as those with company logos, can be changed -- with the change automatically propagating to those children that reference it. This can cause performance problems if the application, and the inheritance, is not designed correctly.

Technical support.

Powersoft provides technical support for PowerBuilder via a toll number from 8 a.m. to 8 p.m., Eastern Standard Time. Powersoft provides free technical support for the platform for 30 days from the point of first contact. After that, the developer must pay for an annual support agreement, or must call a 900 number. Damore (1994) notes that Powersoft is having a hard time keeping with the demand: The company receives 700 calls daily, with users waiting up to 30 minutes to get help. Powersoft has reacted by adding more technical support staff, and dedicating resources to monitor and respond to queries posted on the Powersoft forum on CompuServe. Powersoft has also distributed a CD-ROM that incorporates its call tracking system and presents users with solutions to common problems.

Strategic partnerships.

The Client/Server Open Development Environment (CODE) initiative is a strategic framework adopted by Powersoft, allowing a business to protect its existing technology investments and work with emerging client/server technology (Mattison, 1994). CODE increases PowerBuilder's market presence, and the functionality of its application environment, by expanding links to other components of client/server technology. Through CODE, Powersoft has created alliances with vendors such as LBMS and Attachmate, allowing PowerBuilder to remain an "open" platform.

PowerBuilder 4.0

Powersoft's recently released PowerBuilder 4.0 is nearly identical to version 3.0, except for some key architectural improvements. PowerBuilder 4.0 exhibits improved speed and now offers 32-bit support, which allows it to run on both Window NT and Windows 95 (Gryphon, 1995). PowerBuilder 4.0 also comes with an integrated C++ compiler which allows developers to create, compile, and debug C++ class objects that can be integrated into PowerBuilder applications. PowerBuilder now supports OLE 2.0, Microsoft's Object Linking and Embedding standard.

Version 4.0 also contains some improvements that enhance the usability of the product and application deployment. Powersoft has added PowerTips, which are balloon help type messages, to the toolbars. PowerTips can be incorporated into PowerBuilder applications as well. PBSetup, although exhibiting a somewhat primitive interface, allows developers to create a customized setup routine for application installation -- thus reducing the burden of distributing a PowerBuilder-developed system.

References

Baum, D. (1994). Standard Commercial Corp: Off the aging mainframe in just 24 months. InfoWorld, Vol. 16, No. 38, p. 89.

Cafasso, R. (1995). PowerBuilder platforms run late. Computerworld, Vol. 29, No. 9, p. 6.

Cox, K. & Walker, D. (1993). User interface design. Singapore: Prentice Hall.

Damore, K. (1994). Powersoft is grappling with support logjam. Infoworld, Vol. 16, No. 3, p. 1,93.

Galitz, W. (1994). It's time to clean your windows: Designing GUIs that work. New York: John Wiley.

Gryphon, R. (1995). PowerBuilder 4.0 improves little by little. InfoWorld, Vol. 17, No. 11, 85-88.

Kay, E. (1995). PowerBuilder: Power enough for complex apps? Datamation, Vol. 41, No. 5, 49-51.

Khoshafian, S. & Abnous, R. (1990). Object orientation: Concepts, languages, databases, user interfaces. New York: John Wiley.

Leavens, A. (1994). Designing GUI applications for windows. New York: M&T Books.

Marcus, A., Smilonich, N., & Thompson, L. (1995). The cross- GUI handbook for multiplatform user interface design. Reading, MA: Addison-Wesley.

Mattison, R. (1994). Introduction to the annual GUI survey. Data Management Review, Vol. 4, No. 10, 13-28.

Mullet, K. & Sano, D. (1995). Designing visual interfaces: Communication oriented techniques. Englewood Cliffs, NJ: Prentice Hall.

Object-oriented interface design: IBM common user access guidelines. (1992). Carmel, IN: Que Corp.

PowerBuilder users guide 3.0. (1993). Concord, MA: Powersoft Corp.

Shneiderman, B. (1992). Designing the user interface: Strategies for effective human-computer interaction (2nd ed.). Reading, MA: Addison Wesley.

The windows interface: An application design guide. (1992). Redmond, WA: Microsoft Press.

Back Matter

Figure 1. The PowerBuilder Desktop with PowerPanel and PowerBar.

Figure 3. The Application Painter displaying the HRDB application structure (i.e., its linked Window and Data Window objects).

Figure 7. The Library Painter.

Figure 8. The Application Debugger.

Figure 9. The completed Human Resource Database screens.

.