Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [platform-swt-dev] Parenting rules in a Custom Composite


Item classes are normally lightweight.  In order to mix lightweight and heavyweight widgets, ToolBar uses a ToolItem configured as a SWT.SEPARATOR and the ToolItem.setControl() method to place a control on top of an item.  You could consider using this strategy.  If the custom composite is for your own internal use, leave the result of adding a mouse down listener to your control unspecifed.  People should be using selection listeners rather than mouse listeners to do actions when the user selects your control.

>I don't want to
>abuse your time. I'm willing to pay for a review of the
>code.


Your money is no good here.



"Brian Sam-Bodden" <bsbodden@xxxxxxxxxxxxxxx>
Sent by: platform-swt-dev-admin@xxxxxxxxxxx

07/06/2004 04:12 PM

Please respond to
platform-swt-dev

To
platform-swt-dev@xxxxxxxxxxx
cc
Subject
Re: [platform-swt-dev] Parenting rules in a Custom Composite





Steve,
 Thanks for the quick response. I see what you are
saying now, a more concrete example would be something
like the Outlook Bar component, in which you have
groups which in turn contain Buttons. So I would have a
n OutlookBar and OutlookBarItem classes.
Now, let's say I instead of having the Item class hold
buttons I want to make it more generic and just have a
setContent(Control c) by which I can add some sort of
Vertical ToolBar component. Then the user would just do
something like:

OutlookBar ob = new OutlookBar(parent, style);
OutlookBarItem obi = new OutlookBarItem(ob, "My
Shortcuts");
VerticalToolBar vt = new VerticalToolBar(ob, ..);
VerticalToolBarItem vti = new ....

Does that make more sense? Would it help I send you
some code that you can actually run? I don't want to
abuse your time. I'm willing to pay for a review of the
code.

Regards,
 Brian

Item classes are by convention "lightweight".
If you are going to use an Item subclass, the parent
should draw
it.  If you are drawing it, then the events will go to
the parent
without you doing anything.  You can simply leave the
mouse event
behavior unspecified.  Are people really going to be
hooking mouse
events on your control?






"Brian Sam-Bodden"
<bsbodden@xxxxxxxxxxxxxxx>
Sent by: platform-swt-dev-admin@xxxxxxxxxxx
07/06/2004 03:18 PM



Please respond to
platform-swt-dev





To
platform-swt-dev@xxxxxxxxxxx


cc



Subject
[platform-swt-dev] Parenting
rules in a Custom Composite








Hi,
 I have a general question about building a
Container-like composite (such as a ToolBar or
TabFolder type of component). Let's say I have my
component, called A which has "groups" of other
components. The "groups" are themselves a composite
that can hold one or more controls such as Buttons, etc.

 Following the conventions of class like ToolBar and
TabFolder I have the classes:

A - the top most container
AItem - descendant of org.eclipse.swt.widgets.Item

My main confusion is how to deal with the event
handlers for the Buttons that I want to place in AItem?

Do I add methods to AItem like Button
createButton(String text) and return the button to the
caller so that they can set their custom event
handlers? I sort of did not want to expose the fact
that I'm using a Button, since I might want to replace
that with a Label, CLabel or my own Custom Button/Label
class. So the other option I'm evaluating is whether to
add methods like void createButton(String text, int
index) and set the handlers with something like void
addMouseListener(int index, MouseListener ml).

Which approach is more in line with the SWT design
philosophy? Any hints would be greatly appreciated.

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

Brian Sam-Bodden
President & Chief Software Architect
Integrallis Software, LLC.
http://www.integrallis.com
_______________________________________________
platform-swt-dev mailing list
platform-swt-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-swt-dev


Back to the top