Re: [ve-dev] SWT code patterns

[Joe Winchester <WINCHEST@xxxxxxxxxx>]

>When you mean the target VM part on the free form will know how to parent this part, what
> do you mean? 

On the live JVM that we use to create the objects we do some magic already.  For example, we have to all of the display.readAndDispatch().  For AWT/Swing when something is dropped without a parent Frame/JFrame we put it onto one so it is realized and we can get the image.  This makes sense for JavaBeans that can be null constructed, and the approach we took was basically that a JavaBean on its own made sense, and the VE just reached into the source - parsed it - and anything that looked visual we allowed the user to compose, irrespective of how that thing might actually be shown.

For SWT we can do the same magic (and we already do) but the problem is that from a coding point of view it makes no sense as we can't generate a stand-alone control that will compile.  Dave is right that we could just follow a protocol such as 
public void createControl(Composite parent){
into which we put the controls.  We will do this where there is a recognized coding pattern (such as JFace preference pages or wizards), but even then it seems to be better that the user specifies the superclass or implenents IPreferencePage, we recognize the stub launcher method, and we actually put the parent composite onto the free form for them.  That way controls could be dropped onto the parent which obviously was the one used to launch the class, however even in that case you could not meaningfully put something onto the free-form canvas on its own.  Even for the example Dave uses where you have 
public Control createControl(Composite parent){
what if there are two free form controls - do we create both of them ?  Which do we return.

Every way you look at it, it seems that the only thing you can put down as top level is a Shell.  Everything else can be put inside a Shell, or else inside a composite that has been put there by the VE automatically because it recognized (from inheritance or from a specific interface or protocol implemented) that a parent composite will be given

Best regards,

Joe Winchester