There may be a problem with the layout feature. Design has two components within a container where the components and the container layout is set to relative. All axis of the container can be moved without affecting the components within. When selecting the container and locking the layout to north west, the components within the container, move anchored to the NW sizing tabs of the container. Not really sure if that’s is what it supposed to do. However, when selecting the container and switching the layout back to relative, not anchored, the container does not change it’s behavior and the components within is still locked on the NW corner. I can see if the components were anchored within the container but it’s a little confusing why the layout mode for the container affects the components within even though the components are set to relative. Tried the same thing on two separate machines and had the same problem. Both machines updated to the latest build.
I don’t see any replies to Joseph’s post. I am encountering a similar problem.
I am laying out a table of labels and multi-state indicators. Each row of the table is a container that includes a rectangle, label and multi-state indicator or numeric display. When the screen is resized in runtime view, things get out of alignment. I experimented with some settings and found that I can anchor the rectangles to all 4 sides of the container and that makes them behave. However, I would like the text to scale, so I have to leave the labels, multi-state indicators and numeric displays relative. The fonts scale OK, but the position of some of the text elements move around randomly so they don’t line up between rows as shown in the attached images. You can see this in the speed row below.
Hmm I’ll have to try and mock this up on Monday
Have you been able to replicate this? Any thoughts on a solution?
We were able to replicate this and I put in a ticket to get it fixed.
Ok I’ve figured out what is going on here. First let me explain what you’re observing, and then I’ll discuss the plan to resolve it. (note that none of this should be a complete suprise as much of it is explained in the user manual, but this case is a somewhat confusing combination of two different things.)
What you’re seeing is “expected behavior” (i.e. not strictly a bug) based upon how relative layout works and specifically with how it preserves aspect ratios.
Take a look at the following diagram, which is a simplification of your window. Here we have two containers, each 50px high, in another container that is 100px high. The two interior containers line up flush against each other. The also each have a Label inside of them. The labels are aligned.
Now consider the case where you resize the outer container, and now it is 91px high. 91 is not divisible by two, so we have two choices here on how to handle this:
Choice #1 is to keep both interior containers the same height (in this case, 45px), but that would create a 1px gap somewhere so that things that were flush are no longer flush. (Side note - this is what we used to do which created the dreaded pipe-gap problem that plagued FactoryPMI)
Choice #2 is to keep all components aligned against their neighbors, so the 1px margin of error gets absorbed in the height of one of the interior containers. As you can see this makes one container 46px high and one container 45px high. Normally this wouldn’t be noticeable, but in this case we’re observing that the labels become mis-aligned.
What is happening is due to the way the relative layout preserves aspect ratio of a container’s contents. If a container becomes a size that doesn’t match its original aspect ratio, it finds the largest area inside itself that is the original aspect ratio, and puts its contents into that area. It centers the contents inside the dimension that has extra room. A picture might help explain this:
So you can see how these two things together are 1) making your containers not the same height which 2) creates unequal aspect ratios which then 3) shifts the contents of some of the containers to maintain aspect ratio.
What I propose is to introduce a new sub-mode for relative layout:
1) Maintain / Center (the current behavior)
2) Maintain / Leading (maintain, but don’t align center, align left/top)
3) Maintain / Trailing (maintain, but don’t align center, align right/bottom)
4) Do Not Maintain (let the contents warp)
In your case I think not maintaining would give you the results you expected.
I should also mention that you could immediately get around this problem by not using the intermediate containers. Just use labels and rectangles and it should all work out.
Thanks for the thorough explanation. I guess this might follow from the general descriptions in the documentation, but, as you said, this is a counter-intuitive example. I think your proposed solution would give the designer maximum flexibility, which would be good. Is this something that will be implemented in a new release quickly (e.g., a week), or is this more complicated and will require more time?
Rectangles and labels are another way to go, but I would like to group the text with the rectangle and containers are the only way to group things in Ignition.
Thanks again for the good explanation.
Its already done. It’ll be in the next beta release.
I just installed 7.2.5-beta2. I don’t see this setting. Should it appear in the layout dialog box? Should it appear only on containers? I am missing it.
Err, it doesn’t look like it actually got included in beta 2. We switched to a new build/deploy system with Ignition 7.2, and we’re still working out kinks with how to use it.
It’ll be in beta 3.
Thanks. Is it typical that beta releases come out weekly? I’ve a factory demonstration next Thursday, and it would be great to clear up this cosmetic defect before then.
Beta-3 will be out tomorrow
I installed beta-3 that came out today and the feature is present. Setting the layout properties of components within a container to not maintain the aspect ratio gives the desired behavior. Thanks!