cancel
Showing results for 
Search instead for 
Did you mean: 

Items Container

Medim priority

An Item container where we could chose how items will be stacked inside of it. Very usefull for creating UI

Status: Need Info

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,

Audrie

Comments
Level 10

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

Flow Staff
Status changed to: Need Info

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,

Audrie

Level 10

@Audrie-MSFT

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

 

https://www.youtube.com/watch?v=x7tLPhnA06w

Level 10

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:

 

  1. Groups do not allow for child controls to be added and removed WITHOUT disbanding the Group and having to create a new one

    Today, when one creates a group if you later want to add another item to the group, there is no way to do this.  While yes, I can select the group and the other control or controls, and tell it to group - the net affect is a NEW group with a NEW name, and all of the group's properties set to their default (empty) values.  

    Removing an item (other than just simply deleting the control, or at least cutting it) is also not possible.  One must ungroup the group, and then recreate a new group.  

    This is very tedious - and when creating "composite controls" is a pain as one ALWAYS wants to add or remove things to it.  
      
  2. 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: 


    • Visible -  So if I have say 4 controls in the group, and let's say that one of them I only want to show in a certain condition (and thus Visible has a formula behind it).  But if I forget this and want go and set Visible on the group that this control is in - I've just now wiped out the formula in that child control

    • ColorFill, etc - Want to set MOST of the items in a group to the same color/fill/etc - but not all...  A group won't help you here - you still must manually select each underlying control (control-click) and then set the common property - each and every time or else (if instead you change it on the group) you wipe out the same properties on all children.  

    • X, Y, Width, Height - While one can make calculations of one item based on another when using a Group (or just controls outside of a Group) - which is very common - even in the Microsoft examples, it is VERY EASY to wipe these formulas out.  

      Let's say that I wanted Control2's X position to be exactly at the end of Control1, I could create a formula for Control2 like:

      X = Control1.X + Control1.Width

      That would handle this.  However, let's now say that I click on the group and then MOVE the group (and thus moving all controls in the group) - which would then affect BOTH the X of Control1 (which may have been a static value and thus is probably fine) but also Control2.X.  

      But instead of PowerApps taking into account that Control2's X is a formula, with a Group, it just calculates the new resulting STATIC value of Control2.X.  So while it "looks like" moving the group resulted in moving Control2 to the "right place" - instead it wiped out the formula and thus there is no longer a direct (calculated) relationship between where Control2 is based on Control1.  And of course no warning.  

      So I've learned to just STOP doing any automatic calculated/formulas when grouping controls as there is almost a 100% likelyhood that they'll be wiped out later, wasting my time.  (its easy to accidently move a group even if you didn't mean to).  

      And of course there is no way to lock a property or even all the properties on a control ourselves (not that I'm aware of - I know that some of the controls when added do have things locked, but once you unlock them, you can't lock back). 

       

      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.  


      But if, instead, I wanted a child control be be visible only if the container is visible AND another condition (say perhaps whether a show a certain gallery versus another based on the top of an object set in a dropdown control or a checkbox- maybe also in the same container), I could instead set the child's Visible property to something like Parent.Visible & ( Checkbox1.Value = true ).
  3. Unable to lock properties so that properties with formulas aren't wiped out when either changing the properties on the group, or even moving the group.  

  4. 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:

 

  1. Base properties

    Container should have "Base" properties that are directly off of it (ie: if a container is defined as "MyContainer", these would be accessed as MyContainer.<propertyname>).  

    Base properties aren't calculated or inherited, but can be set and then used (or not) by the child controls using Parent.<propertyname>

    Some examples of "base properties" might be be VisibileDisplayMode, TooltipPaddingTopPaddingBottomPaddingLeftPaddingRight, etc.  So a child control could choose to set its Visible property to Parent.Visible if it wanted its visibility based on the Container, or even provide additional conditions, ie: Parent.Visible & ( Checkbox1.Value = true ).  

    Note that base properties would NOT include ones that I would consider "Calculated" properties (that would also be accessed directly off the container, ie: MyContainer.<propertyname>).  

    So for instance, these would NOT be base properties: XYWidth, and Height as some examples (see Calculated properties).  

  2. Calculated properties

    Like Base properties, Calculated properties would also be would be accessed off the Container object (ie: MyContainer.<propertyname>).  

    However, instead of just being settable, these would be calculated based on the underlying properties of its child controls.  

    Some examples of Calculated properties would be XYWidth, and Height

    So here, these would be calculated as:

    X - the min(X) of all the controls (possibly minus PaddingLeft of the container itself)
    Y - the min(Y) of all the controls (possible minus PaddingTop of the container itself)
    Width - The width of the "minimum bounding box" that is required to house all the child controls (perhaps increased by PaddingLeft and PaddingRight of the container itself)
    Height - The height of the "minimum bounding box" that is required to house all the child controls (perhaps increased by PaddingTop and PaddingBottom of the container itself)

    The above examples would allow me to know exactly what screen real estate the Container and its child controls would take up (or at least its bounding box).  Which would be very useful in calculating how to place other controls in relation to those in containers.  

    If we had a base (not calculated) Fill property on the Container, then this with the X, Y, Width, and Height properties to provide an easy way to fill (which would be bottom most of course) in the container - without needing a rectange or other object.  ie: this would make it easy to create a dialog.  

    If I were to move the container - (affecting the X and Y of its children) or potentially resize the container (POSSIBLY affecting the Width and Height of its children), the container's X, Y, Width, and Height would be recalculated dynamically as its children move/resize.  

    So here calculated properties would be READ ONLY and could not be set, as they are entirely based on the properties of its children (perhaps in relation to other of the Container's properties).

  3. Inherited properties 

    Containers could potentially dynamically inherit the same properties (names) of all of the child controls it contained.  ie: if I had 3 controls within them and 2 had say Text properties and one (say an HTML Text control) had an HtmlText property, then the Container might make both Text and HtmlText available within it.  

    However, these should not be off the "core" Container object, but most likely in a sub property under the Container, ie: let's call that Inherited, so for Container called MyContainer these would be accessed as MyContainer.Inherited.<propertyname>

    (NOTE: much of the functionality in Inherited properties could be gained by the next item - Custom properties - though these would be nice to have as they would automatically be available).  
     
    This would be the most similar to the properties on a group - EXCEPT that the equivalent properties on the child controls would NOT be changed directly.  The child would choose to use these those via the Parent operator.  ie: if I wanted half of the child controls to all have the same Color, I could set their Color property to Parent.Inherited.Color, but the color of the others would be unaffected.  

    Allowing these properties to be "dynamically updated" (in the studio editor of course, not when the app is running) might allow say, 3 HMTL text controls to have the Container show "HtmlText" as an Inherited property, where if I didn't have HTML text controls in the Container, this would not show up.  

    This would also allow me to set - for instance - 5 controls to have the same X property by using Parent.Inherited.X while allowing the other controls to have different properties.  

    Note that in this example any of the "Inherited" properties could be set, unlike the calculated ones...  so MyControl.X (to children also known as Parent.X) is calculated based on the min X of all of its children - and thus readonly (at least by its children - perhaps another control could change - causing the Container to reverse calculate where its children's X should end up - that would be cool), but MyControl.Inherited.X could be set directly.

    It should also be noted that child controls should NOT be allowed to use inherited properties in their own definition for their equivalent property as this would cause issues (ie: the child's X property should NOT be able to be set using Parent.Inherited.X (or the equivalent <ParentContainerName>.X) as this could be recursive and really mess things up...  🙂 ).  

    Not all child controls would have to have all of the inherited/shared properties in order for the Container to "inherit" them.

    Again - Inherited properties would be really nice to have - but technically one could (manually) do the same thing with Custom properties (and I see Custom properties as being very important).  See below.

  4. Custom properties

    One of the biggest things needed in my opinion is for "Custom" properties on a control.  While I could also recommend that each control allow for its own set of "Custom" properties - doing these entirely within a Container is perhaps better.

    So like Inherited properties, these would be located under the Container property in a property called Custom, so this would be accessed (assuming a container called "MyContainer" is defined) as MyContainer.Custom.<propertyname> while child controls could also access these via Parent.Custom.<propertyname>

    This way I could define custom properties that might be used by some or all of the controls in a Container - or accessed externally.  

    So I could for instance use this for Themes - ie: I could define custom properties for colors, fills, etc for different types of controls, and then they would just access this via Parent.Custom.<propertyname>.

    They might also contain a reference to a collection, for instance, that many controls might reference (ie: say a collection that a gallery uses to display and that a text control might do a CountRows on, etc).  Having this in a central place allows it to be easily changed if the Container is copied and pasted.  

    There are TONS of uses for this.  And while yes I could create a collection outside of a Container or group and do something like this - this has TONS of drawbacks - ie: I'd have to create it separately, and KNOW that I've created it and copy and paste it when I copy and past the controls, and if I did, I'd also have to remember to change ALL of the controls to use the new collection instead.  I'm doing all of this today (as I imagine many others are), and its a pain.

    Note that while I think having the ability to access this way (MyContainer.Custom.<propertyname>) is the best way, alternatively, having a "CustomProperties" property off of Container that was a collection would provide at least some of these benefits.  So this "CustomProperties" collection would has "Name" and "Value" fields where the "Name" would be set to the <propertyname> and <value> to the actual value (ie: the prior example of MyContainer.Custom.<propertyname> would be accessed as LookUp( MyContainer.Custom, <propertyname> )).  This has some limitations (other than having to use Lookup() as well as having to use Patch() to update), but might be easier for the PowerApps product team to implement.  
Level: Powered On

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.