Re: [ve-dev] Read/Write of complex LayoutManager values

[Rich Kulp <richkulp@xxxxxxxxxx>]

Hi,

You can do it the other way around,
work it out from the top-down. That's pretty much what we do. Basically
walk through the "components" setting of the container and get
each ComponentConstraint. From there you can get the actual component and
the constraint IJavaInstances. From the constraint you can get the row,col,
and spans, either by querying it from the live constraints (if you had
exposed those) or by parsing the java allocation parse tree. We usually
query the values because the values are typically exposed as standard properties,
so we just use constraint.eGet(feature) to retrieve them.

Now this will give you only those that
were explicitly added by VE. Any that were implicitly added through some
other means won't be know about.

But if you must work it out from the
bottom up, it's a little more complicated. I would get your data back from
the remote vm and create a hashmap where the key would be the IBeanProxy
of the child object as returned from the remote vm, and the value would
be the rest of the IBeanProxy constraint data for the object as returned
from your query. Then you would walk through all of the "components"
settings of the container, get the ComponentConstraint object, then get
the component feature IJavaInstance, from the IJavaInstance get the IBeanProxy
(using BeanProxyUtilities.getBeanProxy(IJavaInstance). This IBeanProxy
will be the same physical instance as the one returned from your remote
vm query and it can be used in your map as the key to retrieve the associated
constraint data.

Rich

Gerald Rosenberg <gerald@xxxxxxxxxx>
Sent by: ve-dev-bounces@xxxxxxxxxxx

06/07/2006 01:34 PM

Please respond to
Discussions people developing code for the Visual Editor project <ve-dev@xxxxxxxxxxx>

To	Discussions people developing code for the Visual Editor project <ve-dev@xxxxxxxxxxx>
cc
Subject	Re: [ve-dev] Read/Write of complex LayoutManager values

Joe - 

The formlayout manager on the remote VM stores all of the live cell constraints
in a single hashmap, using Java object references to the actual components
(jLabel, jButton, etc) as the keys and correspnding cell constraints objects
as values.  No problem accessing the hashmap and digging out individual
constraint values.  I have this code implemented and working.

Just stopped short by the need to somehow correlate a bare Java object
reference (ex: JLabel, id=81) in the remote VM to a specific local VE component
reference that can be used in a VE command to rewrite that specific line
of code.

For example, given *only* a user indication of a desire to insert a column
at 3, this source code

jPanel.add(jLabel3,
new
CellConstraints(2, 2, 3, 1)); // args: col, row, spanX, spanY
jPanel.add(jLabel1,
new
CellConstraints(4, 2)); // args: col, row

will need to be rewritten as 

jPanel.add(jLabel3,
new
CellConstraints(2, 2, 4, 1)); // increase spanX
jPanel.add(jLabel1,
new
CellConstraints(5, 2)); // shift column right

I can figure out which remote components are affected from the constraint
data in the remote VM, but I then need to *somehow* correlate those remote
components to existing local VE objects that can be used in VE commands
to implement the rewrite.

Did not see a way to solve this problem, so thought to explore retriving
the constraint data fully within the context of the local VM (really expected
that it would not be much of a problem for VE).  

So, is there a VE way to correlate remote component instances to local
VE objects?  Something else that I am missing?


At 12:46 PM 6/7/2006, you wrote:
Hi Gerald, 

First - why do you want the constructor args ?  

In the generated source, the unique values of a constraint are specified
as constructor values (no getter/setters are available).  

The only reason I can think to want to do this [parse
tree stuff] ... is because ... you want to do something clever in code
gen.  

Clever, no.  At least no more clever than ordinary VE stuff.  Just
looking for the simplest implementation that can actually work.

Do you see the problem with closing the component identification loop from
the remote VM? Is there a way to surmount, dodge or finese this problem?
 Another alternative?  I certainly hope so.

Appreciate any help and advice,
Gerald
_______________________________________________
ve-dev mailing list
ve-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ve-dev