vroubine wrote:1) Our widgets encapsulate SWT and Nebula widgets and do not inherit from Composite
vroubine wrote:2) We use factories to create Widgets and our constructors do not have only two parameters (Composite parent, int style), but much more, e.g. whether widget is mandatory, expandable, read only and so on
vroubine wrote:3) For creating some sub-widgets, we are not using constructors but FormToolkit
vroubine wrote:4) We can attach default Actions (our proprietary Actions) to widget
vroubine wrote:5) Unfortunately, when we started (several years ago), we did not use Eclipse Data Binding, but created our own framework, which is based on IDs of widgets, etc.
vroubine wrote:Could you help us and give hints how to refactor such kind of widgets in order to be compatible with the SWT Designer.
vroubine wrote:I suppose that similar requirements are coming from more and more customers, since plenty companies have proprietary widgets and/or frameworks.
vroubine wrote:This is exactly the case where the common advice "encapsulate and not inherit" works against us.
vroubine wrote:1) I can not use the SWT-Designer Design Mode for this class, probably since we are using FormToolkit;
private static FormToolkit formToolkit = new FormToolkit(Display.getDefault());
vroubine wrote:2) When putting widget to the View, in the properties I see only "mandatory" field, "uiElementContext" is not seen.
vroubine wrote:3) When creating factory from the widget, in the "Creation Arguments" I see only "parent" and "style" attributes, the others are not available.
vroubine wrote:For us, it is important that we have a possibility to pass multiple arguments, such as context, to the factory method.
vroubine wrote:we have to get a feeling about stability and scalability of your tool.
Users browsing this forum: Bing [Bot], Google [Bot] and 2 guests