HTML Markup | JavaScript | Java | Home & Links

Tutorial 14 - GUI Views & Studies

This tutorial contains GUI builders, color and file choosers and various useful GUI views and case studies that show how objects can act as reusable modules when constructing more complex programs. Reuse can be through cut/paste, include macros or class packaging depending on object stability and project complexity. The case studies illustrate how easy it is to apply different GUI views to an application model if the MVC model has been used and some basic methods included in each application.

GUI Builders

The complexity of designing Java GUI interfaces from scratch beg for GUI building utilities. The advantages of using a GUI builder is that the design and visual rendering stage can be isolated from the coding stage. Human factors specialists and analysts are the best choice for design. Artists are the best for rendering the look. And of course programmers for the coding. Prototype or demo screens can be rapidly developed or modified to client needs prior to hard coding. The tradeoff is that the resulting code will never be as efficient or elegant or as easy to maintain as coded from scratch methods.

Three strategies exist in menu builder utilities: visual drag/drop templates, scripting and XML files made by a visual design program such as QtDesigner. Each method generates a framework that the programmer adds action 'code' to.

Visual designers can be stand-alone utilities such as jGoodies Forms and FormLayoutMaker or embedded in an IDE such as NetBeans and JBuilder.

Color Choosers

The JColorChooser class allows visual selection of colors from a dialog box. A simple example using an inner listener class is:

File Choosers

The JFileChooser class allows browsing the system and selecting appropriate files and/or directories. The JFileChooser(string) constructor can be used to set the starting browse point (currentDirectory is common). setMultiSelectionEnabled(false) limits selection to one at a time. setFileSelectionMode(mode) can be used to limit selection to files or directories only. File/directory selections are returned using the getSelectedFiles() and getSelectedFile() methods. Dialogs are created with showOpenDialog(ClassName.this) and showOpenDialog(ClassName.this). Unfortunately the only difference is in the approval button caption. For some bizarre reason you are allowed to open a nonexistent file by typing a random name in the 'File Name' entry box.

An external FileNameExtensionFilter can be added using addChoosableFileFilter() to limit the scope of selections.

Warning: Use getCanonicalPath() to retain the directory path information when translating from a File to a String object! This method requires Exception handling. Use getName() only when the string will be used for simple display purposes.

Here is one version of the ExtFilter class. The class receives either an extension or list of extensions and a description of the extension(s).

Screen GUI

Sgui provides two text areas, one for typed (or cut/paste)input and the other for output of processed data (use cut/paste to capture). In addition, controls are provided for: Run, Clear, Help, About and Exit. The GUI consists of two layers. The first layer splits the panel into two columns, one for the text areas, the other for action buttons. For now the only RUN processing is a simple uppercasing of all text entered. The RUN button should be deactivated (grayed out) until there is data to work with. The GUI looks as follows:

[screengui]

File GUI

Fgui can access directories to select input and output files. This provides the basis for many utilities that analyze input files and prepare output report files. The GUI consists of two layers. The first layer splits the panel into two columns, one for file selection, the other for run-time function buttons. The next layers consist of two rows (left hand) and a single column (right). File choosers and run-time buttons are the only control objects required in this simple design. The RUN button should be deactivated (grayed out) until the input file is selected. The file text areas should be read only as names must be selected in browse mode. The file chooser should not allow directories to be selected. The input file must already exist. The output selector should have a default of report.txt and allow a new file to be created. The GUI looks as follows:

[filegui]

Combination GUI

Cgui combines the ability to fetch text from files with adding (or cut/pasting) text to a workspace. This gui can form the basis for many useful utilities that analyze input files and prepare output report files. Another advantage over the basic file io GUI is that the user can monitor changes prior to file saving. The GUI consists of two layers. The first layer splits the panel into two columns, one for the workspace, the other for action buttons. File choosers and buttons are the only control objects required in this simple design. The RUN button should be deactivated (grayed out) until the input file is selected. The file chooser should not allow directories to be selected. Any input file must already exist. The output selector should have a default of report.txt and allow a new file to be created. The GUI looks as follows:

[textfilegui]

Batch GUI

Bgui allows multiple input files to be selected. Output files will be created with the same names as the input files but with a different extension (set using OPTIONS). This allows a batch operation effect for file conversion utilities. The interface consists of two layers. The first layer splits the panel into two columns, one for buttons, the other for a list of selected files. In addition to buttons and a listbox, a file chooser selected by the ADD button is required. The file chooser should not allow directories to be selected. Duplicated entries should not occur. Bgui adds the control buttons as an array set with tooltips. The GUI looks as follows:

[batchgui]

Case Studies

wordCount began as a project in string tokenization and was extended with file io. It can now be enhanced by adding a file IO GUI view. You may even wish to isolate the WC_Model class into its own file for separate compilation. Note: Production use reveals a major shortcoming of WordCount. It was designed using fixed size arrays. Implementers should use dynamic lists to make it RealWorld Ready! You can also make sourcing more flexible (typing, cut/pasting or from files) by changing the GUI to a combo GUI.

XCheck began as a project in ad hoc string tokenization and was extended with file io. It can now be enhanced by adding a file IO GUI view.



JR's HomePage | Comments [jatutore.htm:2012 06 18]