-
I have a strange behavior when building a GCompartment using the I follow the documentation for Layout Container with freeform Layout. My parent node uses a VBOX layout adding a Header with a label and add the container. My code is a direct adoption form the documentation and looks very simple like this :
This results in a 'rect' placed somehow randomly in my parent GNode: The computed width and height makes no sense at all as I set the values 800x200 At the end I can place nodes inside my Parent Node which looks fine on a first look. But When a new element is placed in the area where the container compartment is placed I can no longer grap and move this node because the container rect blocks this. Now, when I use the following Builder options where I do not set any layoutOptions like this:
everything is working great. The compartment rect has now a size of 0x0 and it does no longer block other childs: I just want to ask about your opinion? For me it looks fine when the ContainerCompartment has no size. It is just used to hold the ChildList of GNode elements. In the moment I am very confused about the documentation which is very clear and the strange behavior of my final component. My requirement is also more complex as the parent node contains so called Lanes with a fixed position and size and also elements which can be moved around. This looks at the end like this: |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments
-
It looks like I found the solution.
After I changed this to a simple
Everything seems now working as expected - I can move the container with its elements and the elements within the container. |
Beta Was this translation helpful? Give feedback.
-
Hi Ralph, Another issue is that mixing hGrab/vGrab ("make the compartment match the size available in the parent, share with siblings if necessary") and "prefHeight/prefWidth" ("Use at least this size, but you can make it bigger if children require it") are not meant to be used together. hGrab/vGrab delegates size management to the parent; prefHeight/prefWidth is intended for manually-resized nodes (Usually top-level elements). minSize would be more appropriate than prefSize in this case. For swimlanes, custom layouts might be required, especially if you intend to manually resize the lanes. If not, then a vBox containing lanes defined with hGrab=true, vGrab=false (and maybe a minSize) should work (Then the actual size of the swimlane will depend on the children present inside it. This approach doesn't give much flexibility regarding margins, however). |
Beta Was this translation helpful? Give feedback.
It looks like I found the solution.
On the client side I defined the container model element as a
StructureCompartmentView
- as used in the workflow example:After I changed this to a simple
SCompartmentView
the 'rect' HTML node is gone:Everything seems now working as expected - I can move the container with its elements and the elements within the container.