Microsoft Visual J# .NET (Core Reference) (Pro-Developer) - page 31

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.