Posted on 2006-09-18 15:09
小小涼粉 閱讀(257)
評論(0) 編輯 收藏
Design decisions:
Most platforms require that widgets be created within the context of a specific parent, so SWT requires that a parent widget be supplied as one of its constructor arguments. Another requirement of many platforms is that certain style settings must be supplied at creation time (for example, buttons can be checkboxes, radio buttons, or simple buttons and text fields can be single- or multi-line).
Style bits are represented by int constants defined in the SWT class. Styles are then OR'ed together and passed as another constructor argument to create the initial style of a widget.
SWT works directly with the native underlying graphic resources, each SWT resource consumes a GUI resource, and timely release of that resource is essential not only for your SWT application's well-being, but also for the well-being of all other GUI programs currently running. Java's garbage collection carries no timeliness guarantees, and would make a poor manager of graphic resources for SWT. So, instead, you as programmer must assume the responsibility.
Fortunately, a widget that is a child of another widget is automatically destroyed when its parent is destroyed. This means that if you properly dispose of a shell, you do not need to dispose of each of its children because they will be disposed of automatically.
----------------------------------------------------------------------------------------
Top-level classes:
Each SWT application needs a display and one or more shells (representing each window frame).
Display: The Display object represents the connection between the application-level SWT classes and the underlying windowing system implementation.
One of the most important tasks of this class is its event-handling mechanism. The Display class maintains a collection of registered event listeners, reads events from the lower-level operating-system event queue, and delivers these events to the appropriate implementations of registered listener logic.
Shell: Every window has a shell representing the window frame with which the user interacts. The Shell object represents a window—either a top-level window or a dialog window. It contains the various controls that make up the application: buttons, text boxes, tables
----------------------------------------------------------------------------------------
Control: The Control class is the abstract superclass of all the dialog and window component classes such as Button, Label, ProgressBar, Sash, Scrollable, and Slider
Composite: Taking a bottom-up view of the world, every control has a parent that is an instance of the class Composite or one of its subclasses. The class Shell, which represents the top-level windows of your application, is a subclass of Composite.
Stated another way, this time from the top down, a display contains a list of top-level shells, where each shell is the root of a tree composed of composites and controls. Composites can contain other composites, allowing the tree to have arbitrary depth. If the child of a shell is another shell, the child is commonly called a dialog shell. A dialog shell always stays in front of the parent shell.