An Item container where we could chose how items will be stacked inside of it. Very usefull for creating UI
Could you further clarify what you mean by an "item container"? Do you mean like a section group in a form?
Would you mind sharing the business situations where this would be used. This way in addition to reviewing updates possible, we can also offer some ideas on how to address the problem today as well?
Thank you for your clarifications,
Just an addition to this. I have to use gallery linked to temporary table to achieve that which is very painful. Just an example for that is a menu with multiple options and each option navigate to different screen. You get an idea... hopefully
I believe it calls CSS GRID in Visual studio. I hasn't been working in VS for 5 years but I remember this because this was the best feature for stacking - organizing items, layout of the screen and it is missing in PA and it can not be replaced with anything. I'm sure you now that but just in case there is some video I have found for it
I was about to open a similar idea. So let me instead expand upon this one...
Yes, basically a Container control (from my perspective) is similar to a Group, however, there are a lot of limitations in a group, and a different use case (that group doesn't fit very well).
Like a group, a container itself wouldn't have any visual aspects (though it might have properties that could have this). A very good use for a Container would be to define custom dialogs.
I'd see a full implementation of my idea for a Container would include properties directly off the container object itself (as does a group) such as Base and Calculated properties I mentioned below, but also subproperties that contain other properties (ie: Inheritied and Custom). See below. This would allow for a GREAT deal of flexibility, and would allow for creating truly (or pretty close to it) custom controls that could be reused throughout the app.
For me the biggest use case for a Container control is to create composite controls that could be reused easily by copying and pasting (here are a lot of issues doing this today with groups of controls).
Some of the limitations of Groups that I think a Collection control (as I envision it and explain further below) would resolve include:
Group properties when changed wipe out equivalent properties of the child controls below it
If a property is set on a Group, then all that really happens is that the equivalent property for ALL child controls within the group is changed/wiped out.
Here's several real life, EVERY DAY examples of how using Groups can wipe out properties of its children:
With a Container (as I envision it)- instead setting the property on the container would NOT automatically change any of the properites on the children within it. Instead, the children could reference the Container's property using Parent if one chose to do so, or not as well. So if the Container had a Visible property and I always wanted a particular child control to have the same value, I'd simply set Visible in the child to be Parent.Visible.
No Custom property support - There is also no way to have custom properties on a Group or control that go along with the control (or group) when you copy and paste it, etc. - you have to instead define an external collection that has no direct tie to the controls (see below). However, even if you do define the external collection, you have to manually "marry up" the controls to its values, and when you copy and paste the control, you have to remember to do the same with the collection - which is problematic as the control now would reference the ORIGINAL collection, and not the new one, so you then have to modify the control to use the NEW collection.And yes there are other ways to do this (a collection of controls is one way), but there are limitations with this approach too, and its all much harder than it should be for an environment created for "non Developers".
So here are some things I'd see as requirements or a Container control in the best of cases. these below are related to its properties:
I agree with BrianR. Although grouping can somewhat do what "Containers" would accomplish, containers could truly be useful.
I too have had issues with adding and removing items from a group without disbanding the whole thing. In fact, there also seems to be some issues where the order in which properties such as dynamic X and Y properties to be carried out in PowerApps when the screen goes visible just fail to fully execute for groups. I totally abanded groups when I experienced this constantly.
What was happending was that I had a group with an X property that referenced a gallery and would place directly to the right of the gallery. This worked in edit mode when I set it up and even in preview mode just after setting it up.
Then I saved for the day but when I came back the next day, it was ignoring the X position to the right of the gallery and effectively had an X value of 0. I redid the X positioning and it worked again but eventually I was done for that session and saved and closed out. Upon the next session, the X position was being ignored again. So for me, the grouping is not only innefficient at doing what containers inherently can do but they also are very unreliable.
To be honest, I did find a workaround and that was to use a gallery as a "container" but I know that's not what the gallery was intended for if I'm not looking to have multiple items in that gallery.