[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
RE: [ve-dev] Codegen for GridBagConstraint
|
Janek,
Sorry but you can't do that. A property
setting of an object will always be in that object's initialize method.
There is no way to put it anywhere else. That is how the decoders know
that it is a property setting for initialization, it is in the same method.
If it was in a different method it would be ignored and assumed it was
a runtime setting that would occur due to an event. If we didn't do that
and just picked it up from any method we would get into trouble because
we would think settings are being applied during initialization that aren't
initialization settings.
But I'm confused. You set the constraints
is a setting on the ULCLabel, but you don't set it on the label, you send
it into the add(label, constraint) instead. You can't have it both ways.
Also I don't know why you are getting
an NPE. It should of put it into the initialize method fine. Gili will
need to check that one out.
Rich
"Janak Mulani"
<janak.mulani@xxxxxxxxx>
Sent by: ve-dev-bounces@xxxxxxxxxxx
07/28/2005 10:04 PM
Please respond to
Discussions people developing code for the Visual Editor project |
|
To
| "Discussions people
developing code for the Visual Editor project" <ve-dev@xxxxxxxxxxx>
|
cc
|
|
Subject
| RE: [ve-dev] Codegen for
GridBagConstraint |
|
Hi Rich,
>>> RK >>
Yes, the "constraint" must not be containment="true".
As I mentioned in my
just sent previous note IJavaInstances must always be containment="false"
while non-IJavaInstances (such as our intermediate object) must be
containment="true".
As for your constraint feature, you said it could be a String or
GridBagConstraint. It should be a IJavaInstance kind of String, not just
a
plain string because you can't mix non-IJavaInstances and IJavaInstances
on
the same feature.
I would also just set the constraint before setting the label into the
container and only use the ruled on the label being set into container.
Saves a little time so that the preset doesn't walk the same stuff twice.
>>>
I am doing what you suggested:
1. On ULCComponent override, for "containment" SF (you refered
to it as
constraint above), set "containment=false".
2. Create JavaObjectInsance for GriBagConstraints and set a feature
gridX
to -1
Command1: ApplyAttribute: Set "containment" SF on ULCLabel
with the above
created
GridBagconstraints object
Command2: Ruled command: set "components" SF on ULCGridBagLayoutPane
with
ULCLabel.
Now while executing the VCEPreset command (command 2 above). It walks
starting with ULCGridBagContainer, ULCLabel, and GridBagConstrints.
It treats GridbagConstraint like a Property and tries to create a local
var.
But while doing so it throws an exception (see log file in attachment).
The
methodRef for the MemberDecoderAdapter is null.
I feel the problem is that it tries to create the init for GBConstraints
in
ULCLabel's init method (getUlcLabel method) because parent of GBConstraint
is ULCLabel.
But is not what I want. I want the local var in the init method of
GridBagLayoutPane as shown below. How do I achieve this?
ULCGridBagLayoutPane getUlcGBLP() {
if (gblp == null) {
gblp = new ULCGridBagLayoutPane();
gbc = new GBConstraints();
gbc.setGridX(-1);
gblp.add(getUlcLabel(), gbc);
}
return gblp;
}
---------
IN Swing:
It creates ConstComp (CC) GBConstraints set to "constraint"
SF.
Then it creates two commands:
Command1: ApplyAttribute: Set "component" SF on CC with
JLabel.
Command2: Ruled command: set "components" SF on JPanel
(with GBLayout)
with CC.
VCEPreset walks CC and then JLabel and GBConstraints and creates the local
var for GBConstraints in getJPanel method.
The parent for GBConstraint is CC.
------
Thanks and regards,
Janak
_______________________________________________
ve-dev mailing list
ve-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ve-dev
Attachment:
.log
Description: Binary data