Creating child nodes in nested containers [message #68256] |
Tue, 04 March 2003 11:38  |
Eclipse User |
|
|
|
Originally posted by: m.spork.NOSPAMtpg.com.au
Hi,
Using the Logic example as a guide - I have been attempting to do a
Circuit like container node where you can create child nodes within
that container node.
The point of difference is that I have a top level container node that
must always contain 2 nested 2nd level container nodes.
So far I have been able to get it working to the point whereby when I
create a model item for the top level container it automatically
creates the two child (2nd level) containers. It will position and
size them so that when the figure factory constructs the figures the
child container figures will be positioned on the top-level container
such that together they cover the entire top-level figure (each child
covers half the top-level container). Hope this makes sense.
The problem I am experiencing is that when I go to drop a node into
the child container - it tries to add it with the top level container
as parent. The top-level container should only ever contain the 2
child containers. The new node needs to be placed into one of the
child containers - depending on which one you actually drop it on.
I have tried both StackLayout and FreeFormLayouts for the containers
without much luck. I found that using StackLayout in the top-level
container meant I couldn't position and size the child containers. So
now I am using FreeFormLayout for both the top level container and the
child containers. This gives me the aforementioned problem - when
attempting to place a new node into one of the child containers the
createCommand gets a Request object with the parent field set to the
top-level container instead of the child container.
Should I be using some other layout class - or doesn't it matter? Is
there something else I'm missing?
Any help would be appreciated.
Thanks very much,
Murray
|
|
|
|
|
|
Re: Creating child nodes in nested containers [message #68299 is a reply to message #68290] |
Tue, 04 March 2003 12:05   |
Eclipse User |
|
|
|
Originally posted by: none.us.ibm.com
Something else you might consider. I don't know about compound state
diagrams, but with a UML class "node", there are two sub-containers. One
for the attributes, and one for methods. It is useful to associate an
EditPart with each container, but it probably is not desirable to allow the
user to interact with the panes. Therefore, the EditParts for the
sub-containers should not be selectable. We added:
boolean EditPart.isSelectable()
just for this purpose. Maybe it applies for you too.
"Murray Spork" <m.spork@NOSPAMtpg.com.au> wrote in message
news:rcm96v8o534if71s5udfh7r0tgctkllb0q@4ax.com...
> On Tue, 4 Mar 2003 11:50:01 -0500, "Randy Hudson" <none@us.ibm.com>
> wrote:
>
> Boy - that was quick Randy! I hoped to save you the bother with my 2nd
> post but you're way to efficient ;-)
>
> [...]
> >> The point of difference is that I have a top level container node that
> >> must always contain 2 nested 2nd level container nodes.
> >
> >Would these 2 2nd level containers happen to be for a UML diagram?
>
> Yes - state chart diagrams - the top level container is a compound
> state.
>
> [...]>
> >> The problem I am experiencing is that when I go to drop a node into
> >> the child container - it tries to add it with the top level container
> >> as parent. The top-level container should only ever contain the 2
> >> child containers. The new node needs to be placed into one of the
> >> child containers - depending on which one you actually drop it on.
> >
> >It sounds like your 2 child containers do not get "targeted". They must
> >have a container editpolicy, such as LayoutEditPolicy, that returns those
> >containers when getTarget(Request) is called.
>
> OK - that helps me understand. I didn't know what the mechanism was
> here - as I said in my other post all I knew was that I was missing
> the container edit policy.
>
> [...]
>
> >The draw2d layout doesn't affect targeting. It is the EditPart's polcies
> >that determine who gets targeted.
>
> >If you are creating a class diagram, you should probably be using the
> >FlowLayout or ToolbarLAyout in draw2d.
>
> OK - thanks for the tip - I haven't looked at ToolbarLAyout yet - I
> will do so now.
>
> Thanks again Randy and sorry for the uneccessary bother.
>
> Murray
|
|
|
|
Re: Creating child nodes in nested containers [message #68326 is a reply to message #68307] |
Tue, 04 March 2003 22:17  |
Eclipse User |
|
|
|
Originally posted by: none.us.ibm.com
We were reserving this method for a while. In the more recent builds the
method is not final.
"Murray Spork" <m.spork@NOSPAMtpg.com.au> wrote in message
news:1pna6vcsq2kh9fj3q63qeqels73osgb4ct@4ax.com...
> On Tue, 4 Mar 2003 12:05:59 -0500, "Randy Hudson" <none@us.ibm.com>
> wrote:
>
> >Something else you might consider. I don't know about compound state
> >diagrams, but with a UML class "node", there are two sub-containers. One
> >for the attributes, and one for methods. It is useful to associate an
> >EditPart with each container, but it probably is not desirable to allow
the
> >user to interact with the panes. Therefore, the EditParts for the
> >sub-containers should not be selectable. We added:
> >
> >boolean EditPart.isSelectable()
>
> Hi Randy,
>
> My container edit part inherits from AbstractEditPart and it appears
> that isSelectable() is made final in that class and therefore not
> overrideable.
>
> Am I inheriting from the wrong EditPart?
>
> Murray
>
|
|
|
Powered by
FUDForum. Page generated in 0.04400 seconds