It will be generated as a local variable
if there are any properties on it. Our philosophy was that if a property
didn't have any subproperties that it wasn't necessary nor wanted to create
a standalone variable. That is because it is used in only one place. If
it is needed in more than one place, which it would be if there were properties
on the property, then it will create a variable for you.
There may be a way to do if for your
particular case. This can be done if the UlcGridBagLayoutPane is your own
class and not a subclass of JPanel (which I believe is correct) AND the
ulcLabel and gbc1 reference is stored in an intermediate object like we
do for JPanel. If that is so, and you really want it to be a separate variable
all of the time, then you would need to do this:
Assume this is the structure of the
intermediate class: I'm actually using ours as an example:
<!-- ConstraintComponent
is the "component" of a java awt Container.
"component"
always needs to be set.
"constraint"
should be set only if the constraint is set (set to null is still considered
to be set).
LayoutManager's shouldn't set constraint,
except if it is a string. LayoutManager2's should, if necessary. -->
<eClassifiers xsi:type="ecore:EClass"
xmi:id="ConstraintComponent" name="ConstraintComponent">
<eStructuralFeatures
xsi:type="ecore:EReference" name="component" xmi:id="ConstraintComponent/component"
eType="java:JavaClass java:/java.awt#Component">
<eAnnotations
xsi:type="jcm:BeanFeatureDecorator" linkType="CHILD"/>
</eStructuralFeatures>
<eStructuralFeatures
xsi:type="ecore:EReference" name="constraint" xmi:id="ConstraintComponent/constraint"
eType="java:JavaClass java:/java.lang#Object" unsettable="true">
<eAnnotations
xsi:type="org.eclipse.ve.internal.jcm:BeanFeatureDecorator" beanLocation="LOCAL"/> </eStructuralFeatures>
The BeanFeatureDecorator is the addition
to take notice of. It says that for any setting of this feature, if that
setting is not already located, then it should make it LOCAL, which means
a variable in the method.
Rich
"Janak Mulani"
<janak.mulani@xxxxxxxxx> Sent by: ve-dev-bounces@xxxxxxxxxxx
07/11/2005 11:43 AM
Please respond to
Discussions people developing code for the Visual Editor project
To
"ve-Dev@Eclipse. Org"
<ve-dev@xxxxxxxxxxx>
cc
Subject
[ve-dev] Codegen for GridBagConstraint
Hello,
We have ULCGridBagLayoutPane container.
When we add a component, say ULCLabel, to that container, we would like
to
generate:
In the getUlcGridBagLayoutPane() method:
GridBagConstraints gbc1 = new GridBagConstraints();
add(getUlcLabel(), gbc1);
I am able to generate (like you do when a comp is added to container in
Bean
Tree):
add(getUlcLabel(),
new GridBagLayoutConstraints());
But how do I generate (like you do when a comp is added to container in
canvas):
GridBagConstraints gbc1 = new GridBagConstraints();
add(getUlcLabel(), gbc1);
Both GridBagConstraints and ULCGridBagLayoutPane are beans in ULC.
Do I need to specify something special in GridBagConstraints.override to
be
able to generate a local variable in method?
----------------
I looked up Eclipse VE for swing.
It seems that when adding to a container with GridbagLayout, you are
generating commands to create:
GridBagConstraints gbc1 = new GridBagConstraints();
in VCEPreset command.
It gets the GridBagConstraints object from ConstraintsComponent and somehow
creates commands that makes the container getter method (getJPanel())
initialiser of GridBagConstraints and makes GridBagConstraints the
member
of that method.
Could you please explain what is it that triggers GridBagConstraint to
be
generated as local variable?
I checked overrides for GridBagLayout and GridBagConstraints but could
not
find anything special.
Prompt reply will be appreciated.
Thanks and regards,
Janak
_______________________________________________
ve-dev mailing list
ve-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ve-dev