Can I include Screen (Data type: Control) in a collection?

[AndrewB]

**Describe the bug**
I would like to populate a collection in the App On Start  that includes a column for Screen (Data type: Control).   This collection would be passed to a component with a gallery control for navigation.    This worked until a few weeks ago.  Now it seems that PowerApps Internal Error is being thrown when trying to add a Screen object to a collection.

Any thoughts?

**To Reproduce**
Steps to reproduce the behavior:
1. Create an instance of the Crisis Communication App found here Crisis communication sample app - Power Apps | Microsoft Docs Create a collection in The App OnStart for a Canvas app

2. Go to 'The App OnStart.'
3. Right click App 'Choose OnStart'
4. Scroll down to 'to the colNav collection, double click and view the columns'
5. See error

**Expected behavior**
You would expect to see values in the following columns:
Screen
Image

If you remove the Screen (//Screen: 'Request Screen') column from being populated on App OnStart, then the Images property will reappear on the home page. If you try to add the Screen column back to the colNav collection it will break.

From what I can tell, the Screen (Data type: Control) is causing an issue when being added to a collection

**Screenshots**

For all Collect(colNav) comment out all entries starting with Screen, then the collection works for images

If I put the Screen column back in the collection then I get the error on the gallery I'm binding to again

If you click on the colNav collection passed to the Home Screen, you'll see that it's not being populated, even though it populated in the App OnStart

If I click on the Items property of the home menu you get the error that the gallery is expecting a different record structure

**Interface(please complete the following information):**
- Browser Edge 90.0.818.49 (Official build)(64bit)

**Additional context**
Add any other context about the problem here.

[RandyHayes]

@AndrewB '

This has actually been an issue with components for a long time.  It's not just the control being adding, this also happens to records and tables in general getting "walked over" by values that should not be there.  I believe there is a major issue with the components when it comes to being able to work with the tables/records properly for complex columns.

BUT...it can be worked around.

So the next question would be - why are you using a collection for this?  

It seems as though the records you're supplying are not the same schema if it is giving the error you have.

How is the Items property of your component defined?

[AndrewB]

Randy,

Thanks for your quick reply.   One of the reasons I am using a collection is based on app settings (yes/no) in a separate admin app, I can evaluate those choices and build a simple collection containing the navigation and icons for the home page.

I'm open to taking another approach.

If I roll the application back to an earlier version it will start working again, however that promoted version will eventually break without any changes if I open it for editing a few days later. 

Some history here, I've been working in this app off and on for the last few months without touching the collection and didn't have any issues.   It seems within the last two weeks that the collection doesn't like the Screen column. 

The reason I say that, is if I comment out that column, the collection is populated and passed successfully to the component.

If I'm in App On Start, the collection is populate, if switch to the home screen, gallery component, the collection is empty, states there is an error in your formula.

App On Start

Home Menu Gallery

[RandyHayes · Accepted solution]

@AndrewB 

Well, one issue is that you have your Items property set to colNav.

You have the Table definition commented out in the Items property...it should be that, not a dependency on the underlying app.  Components are meant to be autonomous and removable and reusable in other apps.  If you component is designed with a dependency on the underlying app...well, it's not a component and more.

But still, the collection is overkill for what you want.  You can work all of this from a basic variable.  You just need to filter it by what you want based on the admin aspects of the other app.  This all works fine.  I know what you are doing with it - I do that often, just no need for a collection.  Not that collections are bad, they just have a place and this is not necessarily one of them.  Plus they are entirely overused!!

Back to the first paragraph, components have issues!!!  I will just restate that they have issues with tables with complex types in them.  Graphics and control objects sometimes will cause this.

Ex..   Recently did one with what I thought was a simple table schema.  Now that schema had some complex columns in it (tables in the column).  Not a problem in the app, but in the component, even then the simple columns were screwed up.   If I supplied a record with, for example and in addition to the other columns - some complex, a column called Col1 with a Value in a record of "Column1" and another called Col2 with a value of "Column 2".  In the component, if I referenced Col1 it would show "Column 2" and if I referenced Col2 it was "Column 1".  Drove me batty!!  After I really nailed down the schema on the component property and a series of save, exits and re-opens, it started to work as expected - didn't feel comfortable about how long it would work and how good I felt about it in production...but, knock on wood, it is still working fine.

So anyway...get your App dependency out of your component to start with and keep the above point in mind.  If no joy still, then we need to look at more about how you are building and using that collection.

[AndrewB]

Randy,

Thanks for your help.   You were right about the items property.   First of all, they named the component property Items...   however,  I took a step back and followed your advice and corrected the properties on all the components that referenced the collection variable with the correct Table definition instead.  I then set property on all the galleries inside the component to the component property for Items.   

In this case, under the Screens tab,  if my component was called HomeMenu_1, with a custom property called Items, I set that property to Sort(colNav,Id);

Then, in the components tab, I set the Items property for the HomeMenu component to the table definition

Then on the actual gallery control inside the component, I set it's Items property to HomeMenu.Items.

I have no idea how this even worked previously.   

Another key item you pointed out that I'm aware of now, is evaluating collections in the UI.  If you are using complex types, then they won't be visible when evaluating the variable.  I thought this was the original issue, but it's more of a rookie mistake not being familiar with PowerApps.

I'm still new, so I'm not familiar with how I would do this from a basic variable.  Are you talking about a record type variable?    Any references to documentation would be helpful.

Thanks for taking the time to evaluate my issue and for providing the right guidance to fix it!

Sincerely,

Andrew

[RandyHayes]

@AndrewB 

Sounds like things are progressing in a positive way!!

So here is the thing about collections, variables and datasources....they are all the same thing!!  The distinctions are this:

- A DataSource is a table of records.  It also has built into it the ability to "communicate" with the session table in the cloud that contains the real data.  It will automatically sync the app datasource table and the cloud session table.

- A collection is a table of records.  The only thing a collection brings to the table is the ability to add or remove rows easily.

- A variable is anything you want it to be...a simple boolean, text, number, etc. or a complete record, or a complete table of records.  It does not have the ability to directly add or remove rows.

So, a DataSource has a lot of overhead to it.  It has all of the data sync aspects that is pretty heavy on the app (but necessary)

A collection is a table with the overhead of the ability to add or remove rows.  It is more heavy weight on your app to have those when not needed.

A variable has no overhead to it and can be anything.

So, looking at your initial collection.  This would be less app intensive:

Set(NavItems, 
    Table(
        {Id: 7,
         ScreenName: Coalesce(varString.MakeRequest, "Make Request"),
         Description: Coalesce(varString.MakeRequestDescription, "Contact us with a request"),
         Screen: 'Request Screen',
         Image: cc_icon_request,
         URL: ""
        }
    )
)

NavItems is now a table with one record in it.

You can add as many as you want.  

Now, about the admin part.  If you have something distinctive in your table record to indicate the "audience"/visibility, let's say there is an admin column.  Then your formula would be this (and I'll add another record for fun) :

Set(NavItems, 
    Table(
        {Id: 7,
         ScreenName: Coalesce(varString.MakeRequest, "Make Request"),
         Description: Coalesce(varString.MakeRequestDescription, "Contact us with a request"),
         Screen: 'Request Screen',
         Image: cc_icon_request,
         URL: "",
         admin: false
        },
        {Id: 8,
         ScreenName: Coalesce(varString.MakeRequest, "Make Wish"),
         Description: Coalesce(varString.MakeRequestDescription, "Wish on your own time"),
         Screen: 'Wish Screen',
         Image: cc_icon_wish,
         URL: "",
         admin: true
        }
    )
)

Now, let's say you have some other variable in your app that indicates that the current user is an admin - let's call it varAdmin,  then on your Items property for the Menu component, you would have this:

   Filter(NavItems, !admin || admin = varAdmin)

For users that are not admin, they would only see record Id 7 from above.  For those that are admin, they would see 7 and 8.

Hopefully that is clear and helpful for you.

[AndrewB]

Awesome.   Thanks for sharing this additional bit of information, this is fantastic!

Sincerely,

Andrew Burns

[RandyHayes]

@AndrewB 

No problem Andrew.  Hope it is all helpful.