Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[ve-dev] More SWT issues

While we're on the topic of SWT support, I thought I'd document a few other
SWT quirks that will need addressing at the codegen and other levels:

* ControlEditor (used by Table, TableTree, and Tree for hooking up edit
controls as editors) inherits from Object


* The approved way to "subclass" an SWT control is to embed it in a
Composite and then make the Composite a decorator of the embedded control.
This works fine until one needs to add children to the embedded control.

For example, suppose someone wanted to subclass Table in order to create a
version that had some default cell editing behavior.  It would still be
necessary for clients to be able to add TableColumns, Widgets, and possibly
ControlEditor objects as children of the *TABLE* in the containership
hierarchy, not as children of the *enclosing* Composite.

Similarly, JFace Viewers don't inherit from anywhere in the SWT hierarchy,
and have the same problem to solve WRT adding child controls.

JFace's solution to this problem is to have a:

public Control getControl();

method that returns the underlying control for clients that need to access
it directly (for whatever reason).

At ASC, in our custom SWT controls, we have followed JFace's lead and always
provide a getControl() method on our SWT controls if the SWT control is
really a Composite that encapsulates some other control.

Therefore, when adding child controls to some arbitrary control, it is
necessary to java.lang.Reflect for a getControl() method and if found, use
the result of calling it as the parent object rather than using the "parent"
control itself.

Establishing this convention will take us a good way toward JFace support in
VE and will automatically support all new SWT and JFace controls that follow
this coding convention.


* There are variations in what class the "parent" argument should be and if
there are style bits across the SWT class hierarchy.  This will need to be
addressed in the target vm.  I've attached a utility class from XSWT that
can construct arbitrary SWT controls.

That's all I can think of right now off the top of my head.

Eric, Kosta, can you think of anything else right now?


Dave




Attachment: ClassBuilder.java
Description: Binary data


Back to the top