RE: [platform-swt-dev] Inheritance and SWT

[Mike_Wilson@xxxxxxxxxx]

Obviously, that's by design. The intent
is that, if you *really* want to subclass the widget, you can still do
so by overriding the method.

On a more fundamental level though,
usually when someone wants to subclass a widget, it's because they are
trying to treat SWT as framework and implement application logic, for example,
in the widget itself. This is the wrong way to use SWT. SWT widgets simply
represent reasonable packagings of the platform widget capabilities. Unless
you find a platform which has a widget that has your application logic
embedded in its operating system code, you shouldn't be trying to subclass
an existing widget to implement it.

For the correct way to build custom,
application specific widgets, see the document:
        http://www.eclipse.org/articles/Article-Writing%20Your%20Own%20Widget/Writing%20Your%20Own%20Widget.htm

McQ.

"Erik Poupaert" <erik.poupaert@xxxxxxxxx> Sent by: platform-swt-dev-admin@xxxxxxxxxxx 02/04/03 08:21 AM Please respond to platform-swt-dev

To:        <platform-swt-dev@xxxxxxxxxxx>         cc:                 Subject:        RE: [platform-swt-dev] Inheritance and SWT

org.eclipse.swt.widgets.Widget.java, line 248 and following:

 * Checks that this class can be subclassed.
 * <p>
 * The SWT class library is intended to be subclassed
 * only at specific, controlled points (most notably,
 * <code>Composite</code> and <code>Canvas</code>
when
 * implementing new widgets). This method enforces this
 * rule unless it is overridden.
 * </p><p>
 * <em>IMPORTANT:</em> By providing an implementation of this
 * method that allows a subclass of a class which does not
 * normally allow subclassing to be created, the implementer
 * agrees to be fully responsible for the fact that any such
 * subclass will likely fail between SWT releases and will be
 * strongly platform specific. No support is provided for
 * user-written classes which are implemented in this fashion.
 * </p><p>
 * The ability to subclass outside of the allowed SWT classes
 * is intended purely to enable those not on the SWT development
 * team to implement patches in order to get around specific
 * limitations in advance of when those limitations can be
 * addressed by the team. Subclassing should not be attempted
 * without an intimate and detailed understanding of the hierarchy.
 * </p>

You can simply override this method in your derived widget by an empty
method. You don't even need to change the SWT source base:

protected void checkSubclass () { //don't throw the exception}

_______________________________________________
platform-swt-dev mailing list
platform-swt-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-swt-dev