|
Re: Binding to custom SWT widget properties [message #674126 is a reply to message #674091] |
Wed, 25 May 2011 22:04 |
Jim Mayer Messages: 18 Registered: July 2009 |
Junior Member |
|
|
OK... I re-read the documentation and answered my own question:
"Only the following predefined SWT control properties may be observed: enabled, visible, toolTipText, selection, min, max, text, items, selectionIndex, foreground, background, font and editable."
-- Jim
|
|
|
|
|
|
Re: Binding to custom SWT widget properties [message #675554 is a reply to message #675520] |
Tue, 31 May 2011 20:30 |
Jim Mayer Messages: 18 Registered: July 2009 |
Junior Member |
|
|
Thanks. That makes sense.
Your last comment leads into another question I was going to ask the forum. Since it's related to the above, I'll ask it here.
The controls that we are creating have substantially richer behavior than the standard SWT widgets, but many of them do not look like tables or lists. We would like to avoid the repetitive binding of sets of properties for each control. Both JFace viewers and Swing models supply mechanisms that would meet our needs.
We've been playing around with WindowBuilder custom JFace Viewers and have found that we can easily build simple viewers that inherit directly from "org.eclipse.jface.viewers.Viewer" successfully. We can bind bean properties on the widget using data binding. Although our objects do have an "input" property, we cannot bind to it because WindowBuilder's JFace data binding seems to be highly specific to tables and lists. This isn't a problem, but I wanted to check to see if using primitive JFace viewers in this way is a "really bad idea" (e.g., likely to cause trouble in the future).
Another approach to adapting complex widgets would look more like Swing's models. We would give our widgets a "model" property and bind that to a bean property in our logic. The widget would then register itself with the model, which would add event listeners, set properties, etc.
In both cases, we would continue to expose the behavior of the control through a low level API in the style of other SWT widgets. This gives us better testability and, when necessary, low level control.
Any thoughts as to which of these two approaches is likely to work better with WindowBuilder? Is there a different approach that's proven successful in other applications?
Thanks.
-- Jim
|
|
|
Powered by
FUDForum. Page generated in 0.03773 seconds