Designing a user interface

Using JBuilder's visual design tools, you can quickly and easily assemble the elements of a user interface (UI) for a Java application or applet. You simply construct the UI with various building blocks chosen from a palette which contains components such as buttons, text areas, lists, dialogs, and menus. Then you set the values of the component properties and attach event-handler code to the component events, telling the program how to respond to UI events.

This section discusses the following elements of creating a user interface with Borland JBuilder's visual design tools:


JBuilder's visual design tools

Borland JBuilder provides tools for visually designing and programming Java classes, allowing you to produce new compound or complex components.

JBuilder's visual design tools include the following:

Requirements for a class to be visually designable

If you want to use the visual design tools on a file, it must meet the following requirements:
  1. It must be a Java file.
  2. It must be is free from syntax errors.
  3. It must contain a public class whose name matches the file name.

Any file that meets the above requirements can be designed using the Component Tree and the Inspector. This allows you to visually design a non-UI class, such as a DataModule.

If you want the UI Designer to appear in the Content Pane, the class must also be a descendant of java.awt.Container. For example, it can extend Frame, Panel, DecoratedFrame, BevelPanel, Dialog, or Applet.

Note: These requirements are all met when you create your files with the Application Wizard or the Applet Wizard.

When you first add a component to your design, the JBuilder visual design tools will make sure that your class has a public default constructor, a public jbInit() method, and that this jbInit() method is called correctly from the default constructor. If JBuilder doesn't find this code, it will add it. It will also add any imports needed by the component.

How JBuilder determines which designers to use for a class


About components and containers

What are components?

Components are the building blocks used by Borland JBuilder's visual design tools to build a program. Each component represents a program element, such as a user-interface object, a database, or a system facility. You build your program by choosing and connecting these elements.

Borland JBuilder comes with a set of ready-to-use components on the Component Palette. You can also supplement these components by creating new components yourself or by installing third-party components.

Components are objects in the true object-oriented programming (OOP) sense. Because they are true objects, Borland JBuilder components exhibit the following:

Each component, therefore, encapsulates some element of a program, such as a window or dialog box, a field in a database, or a system timer. UI components must ultimately extend either java.awt.Component or extend some other class that derives from it such as java.awt.Panel or java.awt.Canvas. Other JavaBeans components do not have this requirement.

Borland JBuilder uses the JavaBeans component model. To be recognized and used in JBuilder, components must conform to the Java Beans specification. For further details about the exact technical requirements for JavaBeans components, see the JBuilder Component Writer's Guide, and JavaSoft's JavaBeans Tutorial at http://java.sun.com:80/nav/read/Tutorial/beans/index.html.

To be useful in a program, a component must provide the means by which it can be manipulated or interact with other components. JavaBeans components accomplish this by providing properties, methods, and events.
Properties
Information about the current state of a component is called a property of the component. Properties can be thought of as named attributes of a component that a user or program can read (get) or write (set). Examples of component properties are height and enabled.
Methods
Components generally have certain actions they can perform on demand. These actions are defined by methods you can call in code to tell the component what to do. Examples of component methods are repaint and validate.
Events
Components provide opportunities for you to attach code to certain occurrences, or events, making components fully interactive. By responding to component events, you bring your program to life. An example of a component event is actionPerformed.

All components have properties, methods, and events built into them. Some of the properties, methods, and events that components provide are actually inherited from ancestor classes, which means they share these elements with other components. For example, all UI components inherit a property called background that represents the background color of the component. Each component can also introduce its own unique properties, methods, and events. For example, the Checkbox component has a property called checkState that indicates whether the box is checked.

Component categories

There are four categories of JavaBeans components JBuilder provides on the Component Palette.

UI components

UI components are classes that derive ultimately from java.awt.Component. These components can be used as controls in a UI design in the UI Designer and will show in the UI Designer when you place them there from the Component Palette. They also appear in the Component Tree in the section labeled "This".

UI components are elements of the program which the user can see and interact with at runtime because they have the capacity to paint themselves on the screen. In general, they look the same at design time as they will at runtime, which facilitates UI layout. Whenever possible, JBuilder's UI components are "live" at design time. For example, a list displays its list of items, or a data grid connected to an active data set displays actual data.

Menu components

Menu components derive from java.awt.MenuComponent. At design time, JBuilder displays menu components in the Menus section in the Component Tree and provides a special Menu Designer.

Data access components

Data access components represent non-UI components used in a database application to connect data-aware controls to data. Data access components do not appear in the UI container at design time, but they do appear in the Component Tree, in the Data Access section, where you can select them for setting properties and attaching event handlers in the Component Inspector.

Other JavaBeans components

Other JavaBeans components represent program elements that do not appear on the surface of your UI or in the UI Designer. But they do appear in the Component Tree in the Others section where you can select them for setting properties and attaching event handlers in the Component Inspector. Examples of these include popup UI elements, such as dialogs, or other non-UI JavaBeans components.

Choosing a component

Borland supplies several types of categories of JavaBeans components on the Component Palette for user interface design: Java AWT components, and Borland UI and other JavaBeans components. Every component on the palette is a Java Bean, intended to be placed into containing classes using a designer.

In many cases, the Borland components are similar to the Java components, and could be used interchangeably. So, how do you decide which ones to use?

Some of the Borland controls have additional advantages over the AWT controls. For example, the Borland ButtonControl can hold an image, where the AWT Button does not. Many of the Borland controls use a model-view.

By comparing AWT and Borland components that perform related tasks, you can determine which components are best suited to a particular task. In many cases there are several components that can all perform the desired action, but you might choose one based on how it looks and works, or how easy it is to use.

For example, if you are writing a simple applet, you may not need the extra features of the Borland component. To keep the file size smaller and to improve the loading time and speed of the applet (due to less imports and smaller classes), you might choose the AWT equivalent instead. However, if you need flexibility and database connectivity, you would choose a Borland control.

The general advantage of the Borland model-view controls over the simpler AWT components is that the Borland controls are data aware and adapt their behavior to the data that is attached to them. Borland controls can easily be connected to sources of data by setting properties of the control. When you do this, the control automatically fills with live data from the data source.

For example, attaching a TableDataSet to a ListControl and setting the column property of the ListControl will automatically cause that ListControl to be filled with data items from the data source.

For a summary comparison of the components, see the table Components on the palette.

For more information on Borland's model-view architecture, see Model-view components in the Component Writer's Guide.

What are containers?

Containers hold and manage other components. These generally appear as panels, frames, and dialogs in a running program. All your visual design work in JBuilder takes place in containers. But it's also important to understand that containers are also components, so as with other components, you interact with them by getting and setting their properties, calling their methods, and responding to their events.

A non-container subclass "composite" can also hold UI components. For example, you can design the Application.java file created by the Application Wizard and drop panels and dialogs into it on the Component Tree.

If a container has only non-UI components, it need not be a subclass of Container, and therefore is not visible at runtime. One example is a DataModule, whose purpose is to instantiate and interconnect a set of data components and make them available to visible UI components in multiple UI containers.

Windows and Panels

A Window is a stand-alone top-level container component with no borders, title bar, or menu bar. Although a Window could be used to implement a popup window, you normally use some subclass of Window in your UI such as one of those listed below, rather than the actual Window Class:

FrameA top-level window with a border and a title. A Frame has standard window controls such as a control menu, buttons to minimize and maximize the window, and controls for resizing the window. It can also contain a menu bar.

Typically, the main UI container for a Java application (as opposed to an applet) will be a customized subclass of Frame. The customization typically instantiates and positions other components on the Frame, sets labels, attaches controls to data, and so forth. Borland JBuilder provides a customized DecoratedFrame as the main container for an application UI in the Designer.

DialogA popup window, similar to a Frame, but it needs a parent and it can't contain a menu bar. Dialogs are used for getting input from the user or to let you know about warnings. Dialogs are usually intended to be transient, or temporary, and can be one of the following types:

Modal: Prevents user input to any other windows in the application until that dialog is dismissed.

Modeless: Lets the user enter information in both the dialog and the application.

FileDialogA basic system- independent file open/save dialog box that enables you to access the file system.

A Panel is a simple UI container, without border or caption, used to group other components, like buttons, check boxes, and text fields. Panels are embedded within some other UI, such as in a Frame or Dialog. They can also be nested within other panels.

AppletA subclass of Panel used to build a program intended to be embedded in an HTML page and run in an HTML browser or applet viewer. Since Applet is a subclass of Panel, it can contain components, but does not have a border or caption.