| 
| 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.05327 seconds