Chapter 4. Graphical User Interfaces

Java has had libraries for building graphical user interfaces (GUIs) since the earliest days of the JDK. The original library was called the Alternative Window Toolkit, and it later became the Abstract Window Toolkit (AWT) in version 1.1 of the JDK. The goal of the AWT was to provide a set of tools for defining the essential structure of a GUI application that would be independent of the operating system. This circumstance would allow a developer to build applications that could function on a wide range of desktops, ranging from X-Windows under UNIX, to Apple Macintosh, to Microsoft Windows.

A GUI application typically comprises forms, controls that can be placed on those forms, and code that's executed in response to events raised by those controls. With Visual J++ 6.0, Microsoft extended the AWT and added some features specific to Windows, which resulted in the Windows Foundation Class (WFC) library. Meanwhile, the AWT followed its own development track and was later replaced by Swing in version 1.2 of the JDK. As we've mentioned in earlier chapters, Microsoft made the strategic decision to use the JDK 1.1.4 as the foundation for Visual J# .NET but to also support much of the added functionality in Visual J++ 6.0. This means that Visual J# .NET allows you to use the AWT and WFC to support existing applications that are ported to J#. But what about Swing? Well, the Microsoft .NET Framework includes the Windows Forms library, which is comparable to Swing and is available to any program that executes using the common language runtime. It can also be used by programs written in languages other than J#, such as C# and Microsoft Visual Basic .NET.

In this chapter, you'll learn more about the implementation of the AWT in J#, and you'll learn how to use the Windows Forms library for building GUIs from scratch with Visual Studio .NET. However, this chapter is intended only to be an overview of the Windows Forms library, so it does not cover building GUI applications with .NET in detail.

Desktop GUIs

Despite all the excitement about Microsoft ASP.NET and Web services, writing desktop GUI applications is what many of us are really interested in. If you've developed applications specifically for Windows in the past, prepare yourself for a pleasant surprise ”things have changed and gotten easier. If you're taking your first steps into pure Windows-based GUI development, you'll find yourself in familiar surroundings because building Windows applications under .NET is similar to traditional Java GUI development.

But before we start looking at GUI development using the.NET Framework, let's take a step back and ask why you'd want to develop applications specifically for Windows. We can answer that question by first looking at how GUIs can be created using Java.

Revisiting Java GUI Development

In a nutshell , Java offers two GUI libraries: the AWT and Swing. The AWT was the first of the libraries to appear. It operates on the premise that a developer can write code that in effect defines an abstraction of a GUI. Specifically, you use generic components to create a GUI, and position these components using a layout manager rather than absolute coordinates. The layout manager is responsible for managing the exact position of controls placed inside it. The AWT defines a number of layout managers that lay out controls in different ways. (The GridLayout class, for example, displays its contents in a rectangular grid format.) The layout manager removes the need for you to understand how the underlying platform manages , sizes, and positions controls. You can write code once and deploy it across many platforms, ensuring that it appears as if it is a native program running on each platform. You don't have to change a single line of code.

At run time, the AWT libraries map AWT forms and widgets onto the structures used by the underlying platform. However, working with an abstract model poses some disadvantages. The most significant of these are

• The developer has little control over the appearance of the GUI when it executes in an environment other than that in which it was originally written.

• Applications have a look and feel based on the operating system they are executing against. There might be inconsistencies when you run the same application on different platforms.

• The AWT model is a highly layered system, with the native platform at the lowest level. As a result, performance can be hindered as the code passes through several levels of indirection at run time.

Figure 4-1 shows a simple text editor application that was developed using AWT running under Windows XP. The AWT implementation under Windows makes the application appear as similar to a native Windows application as possible.

The AWT will present the same application running on a different operating system using that operating system's look and feel. For example, Figure 4-2 shows the editor application running using the Enlightenment Window Manager under Linux. (The Java class file was copied to the Linux machine and run unchanged.)

Lack of control over the presentation style was a major factor that led to the creation of the Swing libraries. Unlike the AWT, Swing applications can be configured to always have the same look and feel regardless of the underlying operating system. This is achieved using the Pluggable Look and Feel (PLAF) feature of the Swing user interface manager. PLAF schemes are available for a variety of operating systems, including Windows and Motif (X-Windows), as well as a generic cross-platform scheme called Metal (which is actually the default). Figure 4-3 shows a Swing implementation of the editor application running under Windows XP, using the Metal PLAF scheme. (The differences between this figure and Figure 4-1 are subtle but significant ”look at how the menu items are rendered, for example.)

The Swing libraries also simplify many of the day-to-day tasks that a GUI developer might need to perform, such as writing to and from the system clipboard.

Today, some Java developers use Swing, and others use the AWT. The actual choice of library is generally based on which platforms the application will be deployed on and how that application should look on those platforms. Just remember that you can write Swing applications and run them on Windows, but you cannot use Visual J# .NET to do it! However, you can use Visual J# .NET to build AWT applications. You'll find an implementation of the java.awt package, along with java.awt.datatransfer, java.awt.event, and java.awt.image, in the assembly vjslib.dll. However, the main reason for the existence of these packages in .NET is to allow you to migrate existing AWT code rather than develop new applications with it.

One issue not directly addressed by Swing is speed. A benefit of using the .NET implementation of the AWT is that it targets only the Windows platform and is less concerned about dynamically adjusting itself to the look and feel of different environments. (The Windows operating system itself handles any adjustments required by different desktop themes.) As a result, the code usually executes faster than the same AWT application running using the Java Virtual Machine (JVM).

Note

If you're porting a J++ application to .NET, the assembly vjswfc.dll supplied with J# contains a .NET implementation of the WFC classes.

If you're developing an application specifically to run under Windows from scratch using Visual J# .NET, you should consider using the Windows Forms library. This library was written and optimized for Windows. The model used is different from that of the AWT or WFC but is arguably more intuitive. And because it is a native .NET library, it is faster still than the Microsoft implementation of the AWT and WFC.

The Windows Forms Library

The Windows Forms library comprises a set of classes and other types located in the System.Windows.Forms namespace. The Form class represents a window or dialog box, and many of the other classes implement the various controls (such as ListBox , DataGrid , and Label ) that you can place on a form.

Unlike some earlier Windows GUI development tools such as Visual Basic 6.0, forms and controls are themselves first-class types that support inheritance. This should not be a surprise to seasoned Java developers because the same is true in the models used by Swing and the AWT, but it is in fact a big change in the Windows GUI development paradigm. This change in Windows GUI development brings Windows much closer to the concepts used by Java, making the transition from Java development to .NET development as painless as possible. Later in this chapter, we'll take a closer look at Windows Forms and compare them to selected aspects of the Swing library.