Community
Participate
Working Groups
There seems to be a specification conflict between org.eclipse.swt.widgets.Table and org.eclipse.swt.custom.TableEditor. Table Javadoc states the following: "Note that although this class is a subclass of Composite, it does not make sense to add Control children to it, or set a layout on it." On the other hand, TableEditor Javadoc states: "The Control provided as the editor must be created with its parent being the Table control specified in the TableEditor constructor." If a Table implementation on a platform is done according to the Javadoc specification then it won't have the support required by TableEditor. Is there a problem with TableEditor or should all the platforms support adding Composite children to Table? In that case the Javadoc/spec has to be changed.
The spec should be changed (also for Tree).
Should there also be a requirement for the SWT implementations that some certain event is always sent when the item rectangles change? Is it possible that on some platform e.g. the item height in a Table is changing but a column resize event nor a resize event for the Table needs to be sent according to the current spec? In this case TableEditor would not update the child control bounds correctly in every situation. It would be good to specify clearly in the Javadoc that the implementation will always send certain event when Table item rectangles change. E.g. a resize event for the Table. Then it is only required to listen to this one event and that will guarantee that the child controls placed in the item rectangles can have their bounds always correctly updated. E.g. on some mobile device platforms it is common that switching between different screens/resolutions cause the fonts and native component layouts to change. However, the sizes/locations of Tables and TableColumns (there might not even be any) don't necessarily change and there is no need to send any events unless it would be required by the spec.
adding Controls to the table or Tree as child controls will sooner or later be needed by a lot of developers. A plain Table limits the development quiet a lot as the table is the central control for most applications.
I softened the words.
Fixed > 20071105
HI Steve could you please let us know what you fixed and where we can find the fix. thanks Sami
I just changed the Javadoc. Creating children of a table has always been legal (but generally discouraged).
One Question here to clarify if I understood this right! Does that mean that the TableEditor will be part of the eswt package? Because right now the class TableEditor is not part of eswt.
No, This was just a needed clarification for the eSWT developers to support the enabler so that eSWT implementations are aware of such a use and do support TableEditor even if it is not part of the eSWT. If you think it should be part of the eSWT specification, you can file an enhancement request against eSWT.
