|
As lots of SWT widgets classes (except
Control and Composite) are tagged using "final" java keyword,
nobody can subclasse them ...
This is not true. There are almost no final
classes in SWT.
In addition, there are a runtime check
for subclassing too ... the method is ... Widget.checkSubclass().
All you need to do for subclassing is to override
this method to unconditionally return true.
The good idea is to subclass only
Control and Composite, and uses Listeners (paint,/mouse) to try
to do the works for other ...
Agreed, that's what SWT devs suggest.
In reality, most
of the methods in org.eclipse.swt.widgets.* are package private, and SWT
devs continue to use package private methods for their current
development.
Where they have public methods with internal
sematics, these are usually prefixed by "internal_" or "win32_" or "motif_", so
your risk of accidentaly overriding/using these is very low.
So your risk of breaking their code in a future
release is 0%, because subclassing their widgets does not give you more API -
all the additional APIs except few cases are package private => invisible to
you.
Now, whether you'll gain anything from
subclassing stuff different from Composite/Canvas is another issue. Read
on.
but I'm right this is too poor solution to
do all what we want (I'd the same problem
because before using SWT we used Trolltech's Qt C++ framework and I was
really disturbed by SWT limitation
on
subclassing).
Why you need so subclass org.eclipse.swt.Button
is beyond me. As I said, you'll gain 0% more API. Fore example, you cannot tweak
the painting of org.eclipse.swt.Button, bc. it is done with package-private
methods, which are different from platform to platform.
By the way, it seems nothing prevents you from
subclassing org.eclipse.swt.custom.* widgets, and this probably makes sense, as
these are platform-neutral..
Finally, this topic had been discussed many
times. Do search before posting. Oh well, I'm violating my own
advice..
Regards,
Ivan
good luck,
Arnaud.
"R.J. Lorimer"
<rjlorimer@xxxxxxxxxxxxxxxx>
Sent by: platform-swt-dev-admin@xxxxxxxxxxx
11/23/2004 03:03 PM
|
Please respond
to
platform-swt-dev |
|
|
To
| <platform-swt-dev@xxxxxxxxxxx>
|
|
cc
|
|
|
Subject
| RE: [platform-swt-dev]
Subclassing Widgets.. |
|
Eric,
Maybe I am wrong (I haven't tried for a long while),
but I was under the
impression that runtime checks were in place that
prevented subclassing in
many cases.
Is this not the case
anymore?
-----Original Message-----
From:
platform-swt-dev-admin@xxxxxxxxxxx
[mailto:platform-swt-dev-admin@xxxxxxxxxxx]
On Behalf Of Eric Clayberg
Sent: Tuesday, November 23, 2004 7:38 AM
To:
platform-swt-dev@xxxxxxxxxxx
Subject: RE: [platform-swt-dev] Subclassing
Widgets..
Samir.
>I read the document and understand the
consequences of subclassing. But
>the Subclassing is a feature of any
object-oriented language and when
>someone creates a subclass he/she is
aware of consequences the
>subclassing can have. In my case I wanted to
subclass the component to
>add some extra features like my custom table
with few predefined menu
>whose functionality is fixed. These things
can be achieved from
>composition but that is not the right way to do
in case of Java.
If you are aware of the consequences and accept that
responsibility, the go
ahead and subclass any widgets that you like. Just
be aware that your
subclass might not be portable across platforms and
might break in a future
release. Aside from that, most SWT widgets can be
subclassed quite easily.
-Eric
_______________________________________________
platform-swt-dev
mailing
list
platform-swt-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-swt-dev
_______________________________________________
platform-swt-dev
mailing
list
platform-swt-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-swt-dev
| 