v8.0.15
After having just tried to use the column container, I’ve found it quite frustrating to rearrange items around with the mouse. It seems anything I try to move will permanently move every other component that I touch in the process.
Entering positions isn’t so bad via editing the properties, however it’s painful having to expand the properties each time you select another component.
It would be great if this container could be revisited and its workflow made easier to use.
There are three notable idiosyncrasies when it comes to moving the components, so I’d curious if you’re perhaps encountering one of them.
When using the Column container, each component has a starting column and span. As components are drawn left-to-right, components with lower starting indexes need to be honored first. So if you have two components with starting indexes of 0 and 2 and both components have a span of 2, but you drag a third component column 1 and release, then the component which had originally been at column 2 must re-calculate its starting index. As we have to honor values left-to-right, the new starting index for the “third” component must be 2 (because the first component is at column 0 with a span of 2) PLUS the span of the third" component.
Secondly, you’re dealing with different breakpoints, which can be done by either clicking the breakpoint in the property editor or actually resizing the container such that it falls within a breakpoints limits. When you move form one breakpoint to another, we re-draw the container with the layout of the selected (or implied) breakpoint. When we do this, it might look like components are shifting, but it’s because we’re moving them to where they have been defined for this breakpoint.
There is another behavior to be aware of: we can’t limit the length of a row to have a combined span of twelve or less, nor can we limit individual spans based on current column index. This means that you could have one component span 11 columns, then place a second component in the same row and modify the second component’s span to be some value greater than 1. When this occurs, it looks like the container has actually moved components onto a second row, but if you look at the dashed lines you’ll see that you’re actually in the same row. As the row is technically in an incorrect state, you’ll see undesirable behaviors when adding removing components because we still need to honor the left-to-right precedence.
If either of these behaviors describe what you’re seeing, there’s only so much we can do to improve the process. I don’t think we can modify the logic used to draw the rows (left-to-right precedence) because the runtime calculations also have to factor in that the row number could change based on the breakpoint in use at a given time. We might be able to provide a warning when a row enters an undesirable state, but we can’t prevent users from binding those values (columnIndex, span), and so the undesirable state might not even occur until a session is running.
Recommendations:
Never set up a layout for a breakpoint until you’ve placed EVERY component the container will hold. This is because when a component is dropped onto the container while deep-selected it will apply that drop location across ALL breakpoints as much as it is able. Depending on the columnIndex/span values of other components, this could cause some shifting due to the left-to-right precedence rule. I always recommend you just throw every component in that you’re going to use, and once you have everything, then you can move from breakpoint to breakpoint and lay everything out how you’d like.
One huge drawback that I’ve been fighting with for the last two years is that if you’re so unfortunate to have to add a component to a column container that you had perfected, adding that component absolutely scrambles the contents. Now you have components sharing a row that you never had before, and you have to start at the bottom and drag components down to new rows.
BUT, don’t make the mistake of dragging a component down until you have a second component to leave behind, or you’ll lose that row altogether. Now you can start all over again.
C’mon guys, this REALLY NEEDS to be revamped. This is my single, biggest complaint against Ignition right now, as we use a LOT of column containers. HUGE, HUGE source of frustration.
One of the reasons I don’t use column containers anymore, that and their other limitations. They’re similar to UDTType parameters: they’re good in theory, but their limitations invalidate them
Hello all, I’ve got several column container tickets (this behavior included) that I’ll be addressing soon. This particular container needs a bit of a UX overhaul.