guidEclipse Forms Programming GuideInitial creation: 21 February 2004Added table wrap sample: 22 February 2004Introduction
This document has been written to help you use the new Eclipse 3.0 feature called 'Eclipse Forms'. The content will eventually move to Eclipse help. In the mean time, you can start experimenting using examples shown below and code in Eclipse 3.0 integration builds.

Eclipse Forms is a plug-in that exposes a set of customs widgets and other supporting classes that were before used as internal to PDE and Update components. They provide for creating polished, 'Web-like' UIs by modestly extending SWT and/or manipulating style bits, colors, fonts and other properties in order to get the desired behavior. This technology was used throughout PDE multi-page editors and will now be available as public API in Eclipse 3.0.

The document represents the state of API at the time of writing. It is possible that some aspects of the API will slightly change until final release. We anticipate only mechanical name changes rather than more fundamental changes.
Problem definition
When Eclipse platform was designed, there were two distinct context in which SWT widgets could appear:
In traditional dialogs (message boxes, dialogs, wizards, preference pages, property pages) In content areas (views and editors)
Controls in dialogs typically used default colors and fonts as provided by the operating system and were layed out using GridLayout in 9 out of 10 cases. The goal was to look like a dialog and fill the dialog space in both directions.

Controls in views and editors were 'stretchy' i.e. they filled the entire content area. Stretchy controls can scroll their content (trees, tables, text areas, lists etc.). The colors and fonts used here were those provided by the system for use in content area (these colors can be obtained from the Display using SWT.LIST_BACKGROUND or SWT.LIST_FOREGROUND keys).

What was missing was the third option where widgets you would normally see in the dialog context are created in views or editors (where you would expect 'stretchy' controls). Several problems needed to be solved:
SWT controls like buttons, labels, composites etc. look strange in the content areas as-is (with the default dialog background) Composites with GridLayout in the content area are problematic because they are not scrolled. Therefore, it is easy to get the controls to clip or start riding one another. Controls in the content area are normally wrapped to fill the provided width. Wrapping is very hard to accomplish with the existing SWT layouts. When problems 1-3 are fixed, the result looks very much like forms in HTML browsers, and a natural leap is to add hyperlinks and mix them with other controls.
Eclipse Forms were designed to solve these problems. They provide:
A concept of a 'form' that is suitable for inclusion into the content area (editor or view) A toolkit that manages colors, hyperlink groups and other aspects of the form, as well as serve as a factory for a number of SWT controls (these controls are created and configured to fit into the form context) A new layout manager that lays out controls using the algorithm similar to HTML tables Custom controls designed to fit into the form (hyperlink, image hyperlink, scrollable composite, section). Multi-page editor where each page is a form (as in PDE). Setup
In order to be able to use Eclipse Forms, all you need to do is add 'org.eclipse.ui.forms' plug-in to your list of required plug-ins. This plug-ins is RCP-friendly in that it does not have dependency on IDE plug-ins (its only dependency is org.eclipse.ui).
Examples
Source code for most of the examples shown in this document can be found in Eclipse repository (HEAD) as org.eclipse.ui.forms.examples. Check them out into the workspace and look inside the 'src' directory in a Java or PDE perspective.
API packages
Eclipse Forms has the following public (API) packages:
org.eclipse.ui.forms - the main package org.eclipse.ui.forms.editor - classes that employ Eclipse Forms on top of the MultiPageEditorPart to create multi-page editors as seen in PDE org.eclipse.ui.forms.events - new events created to support custom widgets org.eclipse.ui.forms.widgets - a set of custom widgets and layouts created specifically for Eclipse Forms Getting Started
We will start playing with Eclipse Forms by creating an empty form in a view. As we said above, views are content areas that require flexible content. Here is the code sample:

package org.eclipse.ui.forms.examples.views;import org.eclipse.swt.widgets.Composite;import org.eclipse.ui.forms.widgets.*;import org.eclipse.ui.part.ViewPart;

public class FormView extends ViewPart { private FormToolkit toolkit; private ScrolledForm form;
/** * This is a callback that will allow us * to create the viewer and initialize it. */ public void createPartControl(Composite parent) { toolkit = new FormToolkit(parent.getDisplay()); form = toolkit.createForm(parent); form.setText("Hello, Eclipse Forms"); }
/** * Passing the focus request to the form. */ public void setFocus() { form.setFocus(); }



/** * This is a callback that will allow us * to create the viewer and initialize it. */ public void createPartControl(Composite parent) { toolkit = new FormToolkit(parent.getDisplay()); form = toolkit.createForm(parent); form.setText("Hello, Eclipse Forms"); }
/** * Passing the focus request to the form. */ public void setFocus() { form.setFocus(); }


/** * Passing the focus request to the form. */ public void setFocus() { form.setFocus(); }

/** * Disposes the toolkit. */ public void dispose() { toolkit.dispose(); super.dispose(); }}
/** * Disposes the toolkit. */ public void dispose() { toolkit.dispose(); super.dispose(); }} org.eclipse.ui.forms.examples.views;import org.eclipse.swt.widgets.Composite;import org.eclipse.ui.forms.widgets.*;import org.eclipse.ui.part.ViewPart;
public class FormView extends ViewPart { private FormToolkit toolkit; private ScrolledForm form;
/** * This is a callback that will allow us * to create the viewer and initialize it. */ public void createPartControl(Composite parent) { toolkit = new FormToolkit(parent.getDisplay()); form = toolkit.createForm(parent); form.setText("Hello, Eclipse Forms"); }
/** * Passing the focus request to the form. */ public void setFocus() { form.setFocus(); }



/** * This is a callback that will allow us * to create the viewer and initialize it. */ public void createPartControl(Composite parent) { toolkit = new FormToolkit(parent.getDisplay()); form = toolkit.createForm(parent); form.setText("Hello, Eclipse Forms"); }
/** * Passing the focus request to the form. */ public void setFocus() { form.setFocus(); }


/** * Passing the focus request to the form. */ public void setFocus() { form.setFocus(); }

/** * Disposes the toolkit. */ public void dispose() { toolkit.dispose(); super.dispose(); }}
/** * Disposes the toolkit. */ public void dispose() { toolkit.dispose(); super.dispose(); }}
 In the snippet above, we have created a view by creating an instance of a toolkit first. We then used the toolkit to create a form. We set the title of the form. It is important not to forget that toolkit manages resources that need to be disposed of (hence the dispose method).

When we register this view with the workbench and run, we get the following:





The form we just created does the following things:

It renders the title we set using setText

It can render a background image behind the title

The title will wrap if there is no space to show it on one line

The form will introduce scroll bars if the content cannot be shown in the provided space

The last item in the list needs some clarification. In some instances, you will want to make the form be a child of a more complex layout that is itself capable of scrolling. In that case, you may want to get all the capabilities of a form, but without scrolling. In that case you would use the class Form instead of ScrolledForm (in fact, ScrolledForm has-a Form as an internal object and delegates most of the methods like setText to it).
Adding content
Now that we have the form view running, we can start adding some content to it. Eclipse forms have a body and all the content should be created there:

public void createPartControl(Composite parent) {toolkit = new FormToolkit(parent.getDisplay());form = toolkit.createForm(parent);form.setText("Hello, Eclipse Forms");GridLayout layout = new GridLayout();form.getBody().setLayout(layout);Hyperlink link = toolkit.createHyperlink(form.getBody(), "Click here.",SWT.WRAP);link.addHyperlinkListener(new HyperlinkAdapter() {public void linkActivated(HyperlinkEvent e) {System.out.println("Link activated!");}});}

Notice that we first set layout on the body, then used the body as a parent to create a hyperlink. Hyperlink control is one of the custom widgets in Eclipse Forms and acts like a label that is clickable. A new type of listener (HyperlinkListener), its default implementation (HyperlinkAdapter) and the even type are all defined in Eclipse Forms to support the hyperlink. Handling events of the hyperlink are very similar to other SWT widgets, as shown in the code above. Our view now looks like this:



Note how hyperlink has focus rectangle painted around it. When the view is activated, focus is transferred to the form, which passes it to the first control capable of accepting focus, our link in this case.
Hyperlink Groups
Form toolkit has hyperlink group that each hyperlink created by it is added to. Hyperlink groups serve several roles:

They capture colors (both normal, hover and active) for all the links in the group

They change colors of the managed links based on their state

They change underlining style of the managed links based on their state

They manage cursors and show busy cursor before link listeners process the link activation, and change it after.

You can change the default settings of the hyperlink group by obtaining the object from the toolkit (getHyperlinkGroup()).

Creating common controls

One of the design goals of Eclipse Forms was to allow common SWT controls to be created in the editor/view content space. Since form body is a normal composite, you can use any layout and control you want inside it. However, remember that 'raw' SWT controls are designed to fit inside a dialog. We will now create some using their constructors by continuing the method above:

layout.numColumns = 2;GridData gd = new GridData();gd.horizontalSpan = 2;link.setLayoutData(gd);Label label = new Label(form.getBody(), SWT.NULL);label.setText("Text field label:");Text text = new Text(form.getBody(), SWT.BORDER);text.setLayoutData(new GridData(GridData.FILL_HORIZONTAL));Button button = new Button(form.getBody(), SWT.CHECK);button.setText("An example of a checkbox in a form");gd = new GridData();gd.horizontalSpan = 2;button.setLayoutData(gd);

We are now using two columns and creating a label, a text field and a checkbox. The result is below:



It is easy to spot the problem - controls created directly look out of place because they think they are in a dialog. This is the reason there are factory methods on the toolkit to create some of the commonly used controls. Factory methods set the correct colors and also hook certain listeners that ensure controls behave correctly when in a form. If we use the corresponding factory methods instead, the code would look like this:

layout.numColumns = 2;GridData gd = new GridData();gd.horizontalSpan = 2;link.setLayoutData(gd);Label label = toolkit.createLabel(form.getBody(), "Text field label:");Text text = toolkit.createText(form.getBody(), "");text.setLayoutData(new GridData(GridData.FILL_HORIZONTAL));Button button = toolkit.createButton(form.getBody(),"An example of a checkbox in a form", SWT.CHECK);gd = new GridData();gd.horizontalSpan = 2;button.setLayoutData(gd);

The view will now look better:



In general, you should use toolkit methods to create all the controls that you can. In case of a control that is not available from the toolkit, you can use the method adapt. This method takes an SWT controls and adapts it for use in the form. Most of the toolkit factory methods call adapt themselves.
Achieving the 'flat' look
One of the recongizable attributes of Eclipse Forms used in PDE editors was the elegant 'flat' look of the controls. All the controls used there were without 3D borders that looks fine in dialogs but out of place in the content space of editors or views. This support is built into the FormToolkit class. However, on some platform it comes at a price of some custom rendering. For example, look at the following screen capture from PDE editor (version 2.1):



Controls like tables, text entries, combo box etc. are rendered with flat one-pixel borders. These borders do not come from controls themselves (SWT.BORDER style is not used). Instead, if the toolkit is instructed, it will add itself as a paint listener to their parent, and draw borders around controls during paint events. In order to make this happen, you need to call toolkit method 'paintBordersFor(parent)' for each composite where you created controls like text, tree, table etc.

Form toolkit knows which controls require a custom border. However, you may create a new one that also need the border that is not on its list. You can give a hint to the toolkit by making the following call:

Control myControl = new MyControl(parent);myControl.setData(FormToolkit.KEY_DRAW_BORDER, FormToolkit.TEXT_BORDER);

or

myControl.setData(FormToolkit.KEY_DRAW_BORDER, FormToolkit.TREE_BORDER);

toolkit.paintBordersFor(parent);

As you can see from the picture above, 'structural' controls like trees, tables etc. have a different border from text areas and you can choose which one to render for your control. Note that this is not needed for control created using toolkit's factory methods.

In Eclipse 3.0, border rendering is not done on Windows XP. Since Eclipse on Windows XP can use skinned widgets, controls like text, table, tree etc. are already flat and further 'fixing' is not needed. In order to be portable, you should call 'paintBordersFor' anyway, and let the toolkit choose what to do depending on the windowing system.
Custom Layouts
Eclipse Forms offer two new layouts over and above those provided by SWT.
TableWrapLayout
Now that we know how to populate the form, lets throw it a curve: change the hyperlink text to be much longer:

link.setText("This is an example of a form that is much longer and will need to wrap.");

Let's see the result on screen:



What happened? Remember that we are using GridLayout. When it asked the link control to compute its size, it gave it the size needed to render the text in one long line. Although we instructed the control to wrap, it didn't matter because GridLayout requires that a control returns its size in isolation. The link itself (as well as other SWT controls like Label) is capable of computing the height given its width (if you pass the width instead of SWT.DEFAULT in computeSize), but GridLayout is not passing it.

What we really need is a different layout algorithm that works more like HTML tables. We want the content to try to fit in the provided client area, and grow vertically to compensate. Eclipse Forms provide an alternative layout for just such purpose called TableWrapLayout. There are many similarities between GridLayout and TableWrapLayout. Both organize parent's children in grids. Both have layout data that instructs the layout how to treat each control. Both can accept hints on which control should grab excess space etc.

However, they fundamentally differ in the approach to layout. TableWrapLayout starts with columns. It computes minimal, preferred and maximum widths of each column and uses this information to assign excess space. It also tries to be fair when dividing space across columns so that there is no excess wrapping for some controls.

It is possible to mix GridLayout and TableWrapLayout but the branch where you use GridLayout is the one where wrapping stops. This is quite acceptable if you don't want it to wrap (if the composite contains controls that cannot wrap anyway, like text, buttons, trees etc.). However, you should have an unbroken path from the form body to each text control that needs to wrap.

Lets rework our example to use TableWrapLayout (changes are highlighted);

public void createPartControl(Composite parent) {toolkit = new FormToolkit(parent.getDisplay());form = toolkit.createForm(parent);form.setText("Hello, Eclipse Forms");TableWrapLayout layout = new TableWrapLayout();form.getBody().setLayout(layout);Hyperlink link = toolkit.createHyperlink(form.getBody(), "Click here.",SWT.WRAP);link.addHyperlinkListener(new HyperlinkAdapter() {public void linkActivated(HyperlinkEvent e) {System.out.println("Link activated!");}});link.setText("This is an example of a form that is much longer and will need to wrap.");layout.numColumns = 2;TableWrapData td = new TableWrapData();td.colspan = 2;link.setLayoutData(td);Label label = toolkit.createLabel(form.getBody(), "Text field label:");Text text = toolkit.createText(form.getBody(), "");td = new TableWrapData(TableWrapData.FILL_GRAB);text.setLayoutData(td);Button button = toolkit.createButton(form.getBody(),"An example of a checkbox in a form", SWT.CHECK);td = new TableWrapData();td.colspan = 2;button.setLayoutData(td);}

Obviously, we used more-less the same concepts. Some of the variables have different names (for example, colspan and rowspan, align and valign are taken from HTML TABLE attributes), but you are doing the same thing - creating a grid with two columns where link and button span two columns. Since margins are the same as in GridLayout, the result will look similar except link will be wrapped as expected:



This is more like it. The way we configured the layout, text control will grab the excess space in its column, and both the checkbox and the link  will just spread across both columns. In addition, link will not try to render in one long line - it will take the view width and push the rest of the content down in order to wrap.

One of the main differences between TableWrapLayout and GridLayout is that with the former you should stop thinking about the vertical dimension. In GridLayout, you would typically let the 'rigid' controls assume their natural positions and let 'flexible' controls (text, tree, table) grab horizontal and/or vertical excess space. In contrast, TableWrapLayout works top-down and when it places all the controls, it is done. The concept of grabbing excess space still exists in horizontal dimension (as shown above). However, vertically you can only choose to FILL the cell in case it is taller than the control, or pick TOP, MIDDLE or BOTTOM vertical alignment.

You may notice one thing that may seem in contradiction with the previous claim: TableWrapData still has grabVertical variable. However, the variable is there for a distinct purpose: when a control with a fixed height spans multiple rows, its height will create a local case where vertical dimension is known, and controls in the spanned cells need to divide the extra space between themselves.

In order to have good results with TableWrapLayout, ensure that controls that need to wrap have the appropriate style (SWT.WRAP). Composite custom controls provided by Eclipse Forms are wrap-enabled out of the box. This is achieved by using internal layouts that implement ILayoutExtension interface:

public interface ILayoutExtension {/** * Computes the minimum width of the parent. All widgets * capable of word wrapping should return the width * of the longest word that cannot be wrapped. * param parent * param changed * return */public int computeMinimumWidth(Composite parent, boolean changed);/** * Computes the maximum width of the parent. All widgets * capable of word wrapping should return the length * of the entire text without wrapping. * param parent * param changed * return */public int computeMaximumWidth(Composite parent, boolean changed); }

TableWrapLayout implements this interface itself, which allows it to handle cases where composites with this layout are children of the composite that is laid out. The additional two methods allow it to compute the two extreme cases - the absolute minimum width and the maximum width if all the controls are spread as wide as possible. The difference between the two allow the algorithm to distribute extra space fairly between columns to minimize excess wrapping.

Let us take a closer look at the space distribution. We will comment the code we wrote so far in the view and replace it with the following:

layout.numColumns = 3;Label label;TableWrapData td;label = toolkit.createLabel(form.getBody(), "Some text to put in the first column", SWT.WRAP);label = toolkit.createLabel(form.getBody() ,"Some text to put in the second column and make it a bit longer so that we can see what happens with column distribution. This text must be the longest so that it can get more space allocated to the columns it belongs to.", SWT.WRAP);td = new TableWrapData();td.colspan = 2;label.setLayoutData(td);label = toolkit.createLabel(form.getBody(), "This text will span two rows and should not grow the column.", SWT.WRAP);td = new TableWrapData();td.rowspan = 2;label.setLayoutData(td);label = toolkit.createLabel(form.getBody(), "This text goes into column 2 and consumes only one cell", SWT.WRAP);label.setLayoutData(new TableWrapData(TableWrapData.FILL_GRAB));label = toolkit.createLabel(form.getBody(), "This text goes into column 3 and consumes only one cell too", SWT.WRAP);label.setLayoutData(new TableWrapData(TableWrapData.FILL));label = toolkit.createLabel(form.getBody(), "This text goes into column 2 and consumes only one cell", SWT.WRAP);label.setLayoutData(new TableWrapData(TableWrapData.FILL_GRAB));label = toolkit.createLabel(form.getBody(), "This text goes into column 3 and consumes only one cell too", SWT.WRAP);label.setLayoutData(new TableWrapData(TableWrapData.FILL));form.getBody().setBackground(form.getBody().getDisplay().getSystemColor(SWT.COLOR_WIDGET_BACKGROUND));

The code above creates a number of wrapping labels with text of variable length. Some labels span columns, some span rows. To make the test easier, we will set the form background to widget background so that cells will be easy to spot. When we run the example, we will get the following:



The key in space distribution is that difference between control minimum and maximum width is compared. If this difference is greater, the control will cause the column width to receive greater allocation of excess width (excess width is any width greater than the width needed to fit all the controls with their minimum widths taken into account). Notice how column 3 is slightly wider than column 2 because text in column 2 is somewhat longer. The overall goal is to avoid too much empty space in cells. If you want to read more about the theory behind the algorithm, go to W3C recommendations for HTML table auto-layout.
Column Layout
Another custom layout in Eclipse Forms is a variation of the RowLayout. If you configure RowLayout to place children vertically (in columns), and to make all controls the same with within the column, we would get several columns (depending on the width of controls), but the last column would typically not be completely filled (depends on the number of controls). Again, if placed in a form, we would get all the controls in one column because RowLayout cannot do 'vertical' wrapping. If we use GridLayout, we must choose the number of columns upfront and live with the choice.

There are situations in more complex forms where we want the number of columns to be adaptive. In other words, we would like it to change depending on the width of the form - use more when possible, drop the number down if the width decreases. We would also like to fill the form area more-less equally (with all the columns roughly the same height). All this can be achieved with ColumnLayout.

Compared to TableWrapLayout, ColumnLayout is much simpler. Hardly any configuration is needed. The only choice you need to make is the range of columns you want to have (default is 1 to 3). The following example shows a form with a large number of sections (we will talk about sections later) using ColumnLayout. Since there is enough space, three columns are used



The sample exact example will drop the number of columns to two when the form is narrowed:



Controls are laid out top-down, left to right. One column is filled, then then the next one etc. However, the space computation first ensures that each column is roughly the same height so that space is used rationally.

You can still tweak the sizing of the individual controls when using ColumnLayout using ColumnLayoutData. For example, if the control is 'stretchy', you may want to limit its width or height by setting width or height hint. By default, controls 'fill' the width of the column, but you can change that by choosing LEFT, CENTER or RIGHT.
Complex controlsExpandable composite
A very common theme in sleek web pages is the ability to collapse a portion of page content using a toggle control. Eclipse Form offers such a control: ExpandableComposite.

ExpandableComposite ec = toolkit.createExpandableComposite(form.getBody(), ExpandableComposite.TREE_NODE);ec.setText("Expandable Composite title");String ctext = "We will now create a somewhat long text so that "+"we can use it as content for the expandable composite. "+"Expandable composite is used to hide or show the text using the "+"toggle control";Label client = toolkit.createLabel(ec, ctext, SWT.WRAP);ec.setClient(client);td = new TableWrapData();td.colspan = 2;ec.setLayoutData(td);ec.addExpansionListener(new ExpansionAdapter() {public void expansionStateChanged(ExpansionEvent e) {form.reflow(true);}});

The composite accepts a number of styles that control its appearance and behavior. Style TREE_NODE will create the toggle control used in a tree widget for expanding and collapsing nodes, while TWISTIE will create a triangle-style toggle. Using EXPANDED will create the control in the initial expanded state. If style COMPACT, control will report width in the collapsed state enough to fit in the title line only (i.e. when collapsed, it will be as compact horizontally as possible).

Control itself is responsible for rendering the toggle control and the title. The control to expand or collapse is set as a client. Note that it is required that the client is a direct child of the expandable composite.

We needed to add expansion listener to the control and reflow the form on the state change. This is because expansion causes changes in expandable composite size, but the change will not take effect until the next time the parent is laid out (hence we need to force it). In general, every time you do something that causes the layout of the form to be invalid, you need to reflow the form. Reflowing the form will position the controls according to the new sizes AND update scroll bars.

The view now looks like this:



When you click on the '+' sign or on the title itself, composite expands to reveal the client:



This is not bad, but we would like to align the client with the title, not the toggle control. If we bitwise-OR CLIENT_INDENT style with TREE_NODE, the client will receive the desired indent:



It goes without saying that expandable composite uses internal layout that implements ILayoutExtension, and can therefore be added to the parent that uses TableWrapLayout.
Section
One of the most versatile custom controls in Eclipse Forms (and seen in all PDE editors) is Section. It extends expandable composite and introduced the following concepts:

Separator - a separator control can be created below the title

Description - an optional description can be added below the title and separator.

The code is not much different than in case of the expandable composite:

Section section = toolkit.createSection(form.getBody(), Section.DESCRIPTION|Section.TWISTIE|Section.EXPANDED);td = new TableWrapData(TableWrapData.FILL);td.colspan = 2;section.setLayoutData(td);section.addExpansionListener(new ExpansionAdapter() {public void expansionStateChanged(ExpansionEvent e) {form.reflow(true);}});section.setText("Section title");toolkit.createCompositeSeparator(section);section.setDescription("This is the description that goes below the title");Composite sectionClient = toolkit.createComposite(section);sectionClient.setLayout(new GridLayout());button = toolkit.createButton(sectionClient, "Radio 1", SWT.RADIO);button = toolkit.createButton(sectionClient, "Radio 2", SWT.RADIO);section.setClient(sectionClient);

This time, we used TWISTIE toggle style, added the description and also created composite separator. The view now looks like this:

 
Image hyperlink
Image hyperlink is a subclass of Hyperlink that adds an image before the link. This combination is so common that it just made a lot of sense to make one control out of it and save on widgets. The control can be used as image link only (when no text is set), or as a combination of link and image. Images for normal, hover and active (selected) state can be set.
Form text control
Using the combination of labels, hyperlinks (and image hyperlinks) and TableWrapLayout, it is possible to create rich form content:



However, soon you will notice that there are limits in how close you can get to the 'web look'. If you inspect the picture above closely, you will notice that all elements are clearly separated: images from text, bold labels from normal labels etc. Images are all at the beginning of the text, not the in the middle. Hyperlinks stand alone - on their own.

To remedy the problem, Eclipse Forms plug-in provides a very rudimentary text control that can do the following:

Render plain wrapped text

Render plain text but convert any segment that starts with http:// into a hyperlink on the fly

Render text with XML tags

In all three modes, form text control is capable of rendering either a string or an input stream.
Rendering normal text (label mode)
FormText rtext = toolkit.createFormText(form.getBody(), true);td = new TableWrapData(TableWrapData.FILL);td.colspan = 2;rtext.setLayoutData(td);String data = "Here is some plain text for the text to render.";rtext.setText(data, false, false);

Second argument set to false means that we will not bother to parse tags, and the third that we will not try to expand URLs if found.
Automatic conversion of URLs into hyperlinks
Now we will add a hyperlink in the text and turn the third argument into true:

FormText rtext = toolkit.createFormText(form.getBody(), true);td = new TableWrapData(TableWrapData.FILL);td.colspan = 2;rtext.setLayoutData(td);String data = "Here is some plain text for the text to render; this text is at http://www.eclipse.org web site.";rtext.setText(data, false, true);

When we look at our view, it now looks like this:



The URL has been converted into a link. The link is part of the wrapped text - we didn't have to create a separate Hyperlink control and try to sandwich it between two labels.

Since rich text control can render hyperlinks, it accepts hyperlink listeners. When created by the toolkit, it assumes hyperlink settings from the hyperlink group that belongs to the toolkit.
Parsing formatting markup
The most powerful use of the form text control is when formatting tags are added to the text. The expected root tag is 'form'. It can one or more children that can either be <p> or <li>. Either of these can have normal text, text between <b> or <span> tags, images and links. Images are declared using <img Objects");section.setDescription("The list contains objects from the model whose details are editable on the right");section.marginWidth = 10;section.marginHeight = 5;toolkit.createCompositeSeparator(section);Composite client = toolkit.createComposite(section, SWT.WRAP);GridLayout layout = new GridLayout();layout.numColumns = 2;layout.marginWidth = 0;layout.marginHeight = 0;client.setLayout(layout);Table t = toolkit.createTable(client, SWT.NULL);GridData gd = new GridData(GridData.FILL_BOTH);gd.heightHint = 20;gd.widthHint = 100;t.setLayoutData(gd);toolkit.paintBordersFor(client);Button b = toolkit.createButton(client, "Add...", SWT.PUSH);gd = new GridData(GridData.VERTICAL_ALIGN_BEGINNING);b.setLayoutData(gd);section.setClient(client);final SectionPart spart = new SectionPart(section);managedForm.addPart(spart);TableViewer viewer = new TableViewer(t);viewer.addSelectionChangedListener(new ISelectionChangedListener() {public void selectionChanged(SelectionChangedEvent event) {managedForm.fireSelectionChanged(spart, event.getSelection());}});viewer.setContentProvider(new MasterContentProvider());viewer.setLabelProvider(new MasterLabelProvider());viewer.setInput(page.getEditor().getEditorInput());}protected void createToolBarActions(ManagedForm managedForm) {final ScrolledForm form = managedForm.getForm();Action haction = new Action("hor", Action.AS_RADIO_BUTTON) {public void run() {sashForm.setOrientation(SWT.HORIZONTAL);form.reflow(true);}};haction.setChecked(true);haction.setToolTipText("Horizontal orientation");haction.setImageDescriptor(ExamplesPlugin.getDefault().getImageRegistry().getDescriptor(ExamplesPlugin.IMG_HORIZONTAL));Action vaction = new Action("ver", Action.AS_RADIO_BUTTON) {public void run() {sashForm.setOrientation(SWT.VERTICAL);form.reflow(true);}};vaction.setChecked(false);vaction.setToolTipText("Vertical orientation");vaction.setImageDescriptor(ExamplesPlugin.getDefault().getImageRegistry().getDescriptor(ExamplesPlugin.IMG_VERTICAL));form.getToolBarManager().add(haction);form.getToolBarManager().add(vaction);}protected void registerPages(DetailsPart detailsPart) {detailsPart.registerPage(TypeOne.class, new TypeOneDetailsPage());detailsPart.registerPage(TypeTwo.class, new TypeTwoDetailsPage());}}

This part can now be used anywhere, but the example it was take from was using it inside a multi-page editor. Two distinct object types were used (TypeOne and TypeTwo), and their classes were used directly as keys (other mapping between details pages and objects are possible). Details pages registered with the detials part need to implement the following interface:

public interface IDetailsPage {void initialize(IManagedForm form);void createContents(Composite parent);void inputChanged(IStructuredSelection selection);void commit();void setFocus();void dispose();boolean isDirty();void refresh();}

The page is first initialized with the managed form to get access to the toolkit and other objects. It is then asked to create contents in the provided parent. It should also set focus on the first control when asked, be able to refresh, commit, dispose and react to the input change. As long as objects in the master part are of the compatible type, the page will stay visible and 'inputChanged' will be called.

Let's see how all this looks in practice (you can read the complete example code in the mentioned example plug-in):



An instance of TypeOne object is selected in the master part. The appropriate page for the type is loaded in the details part. Obviously the page can contain any number of controls introduced in the preceding text. The ratio of parts on the page can be changed by scrolling the sash (shown in the picture on mouse down). Also note two actions in the upper-right corner of the form - this is the form tool bar. In this case, two radio buttons were contributed to control orientation of the part (horizontal or vertical).

If we change the orientation and also select one of the TypeTwo instances, we get into the following state:



Orientation is now vertical, and a different details page is shown for the type.

It is possible to register detail page provider instead of registering pages upfront. This allows dynamic resolution of the object that has been selected.
Multi-page form editors
It was a long way to this topic, yet PDE multi-page editors were the first to spark interest in Eclipse Forms. Today, multi-page editors still represent the widest users of the technology, even though it now starts to appear in other places.

Eclipse Forms are designed to work in a widest variety of settings. For this reason, the plug-in cannot make assumptions of the types of editor inputs your editor can have. A number of concepts employed in PDE UI cannot be used here because without knowing about the editor input in more detail, it is hard to provide reusable set of classes. Nevertheless, Eclipse Forms provide the basic support for multi-page editors you can build on.

You should start building an Eclipse Forms multi-page editor by extending FormEditor:

public class SimpleFormEditor extends FormEditor {/** * */public SimpleFormEditor() {}/* * (non-Javadoc) * see org.eclipse.ui.forms.editor.FormEditor#createToolkit(org.eclipse.swt.widgets.Display) */protected FormToolkit createToolkit(Display display) {// Create a toolkit that shares colors between editors.return new FormToolkit(ExamplesPlugin.getDefault().getFormColors(display));}/* * (non-Javadoc) * * see org.eclipse.ui.forms.editor.FormEditor#addPages() */protected void addPages() {try {addPage(new FreeFormPage(this));addPage(new SecondPage(this));addPage(new ThirdPage(this));addPage(new ScrolledPropertiesPage(this));addPage(new PageWithSubPages(this));}catch (PartInitException e) {/