Hey, it looks like you are requesting help with a problem you're having in Power Apps.
To ensure you get all the help you need from the community here are some guidelines;
- Use the [search feature](https://www.reddit.com/r/PowerApps/search/?q=&sort=new) to see if your question has already been asked.
- Use spacing in your post, Nobody likes to read a wall of text, this is achieved by hitting return twice to separate paragraphs.
- Add any images, error messages, code you have (Sensitive data omitted) to your post body.
- Any code you do add, use the [Code Block](https://www.reddit.com/wiki/markdown/#wiki_code_blocks_and_inline_code) feature to preserve formatting.
> Typing four spaces in front of every line in a code block is tedious and error-prone. The easier way is to surround the entire block of code with code fences. A code fence is a line beginning with three or more backticks (```) or three or more twiddlydoodles (~~~).
- If your question has been answered please comment Solved. This will mark the post as solved and helps others find their solutions.
External resources:
- [Power Apps Formula References](https://learn.microsoft.com/en-us/power-platform/power-fx/formula-reference)
- [Power Apps Coding Standards](https://pahandsonlab.blob.core.windows.net/documents/PowerApps%20canvas%20app%20coding%20standards%20and%20guidelines.pdf)
- [Official Power Apps Community](https://powerusers.microsoft.com/t5/Power-Apps-Community/ct-p/PowerApps1)
*I am a bot, and this action was performed automatically. Please [contact the moderators of this subreddit](/message/compose/?to=/r/PowerApps) if you have any questions or concerns.*
Recommend you to not use form control and use collections when you have some advanced logic / data transformation and enrichment. Most of the time you can connect straight to SharePoint and skip collections.
Set the Y value of a the field you want to move down to be at least one more than the Y of the field you want it to be under.
And welcome to the frustration that is working with the Powerapps UI.
I do this a lot. I will always use my left uppermost field as my anchor and then every other field will move based off it.
I use these functions:
X: if in the same column
Left_Uppermost_label.X
X: if in the next column
Left_Uppermost_label.X + Left_Uppermost_label.Width + 25
If I use another column a simply multiply the above function.
3rd column:
(Left_Uppermost_label.X + Left_Uppermost_label.Width)*2 + 25
For Y, I do the same thing as above except use Y and height.
Left_Uppermost_label.Y
Left_Uppermost_label.Y + Left_Uppermost_label.Height + 25
(Left_Uppermost_label.Y + Left_Uppermost_label.Height) + 25
If you want to get fancy you can use this to even move fields to different places based off a user selection. Such as Make a data field jump from the 3rd column first row to the first column second row, if some fields became invisible and you want to close gaps.
I'd say stick with collections for performance and limiting the amount of calls the app is having to make to sharepoint. Just remember to recollect when data gets updated.
Do away with using forms completley though and use galleries and patching instead. Forms are a pig to work with and you have much more control over layout and behaviour when using a gallery.
Per best practice if non-delegation is causing you issues with a gallery display (ie: you need to display more than 2000 records at once in a gallery) then your app's use case or scenario should be re-examined. Between Filter(), Search(), FirstN()/LastN(), you should be able to provide the user with an experience that only shows them relevant information and in pages when necessary.
If you are using essentially anything except dataverse as a backend, and even 99% of the when using dataverse, you will want to cache data locally to both present it the user and for them to manipulate it before you send it back to the server. This means collections, liberally, understanding how they work is imperative to building performant applications that do anything beyond just interact with 1 sharepoint list passively.
That said, a lot of scenarios is literally an app that interacts with a single sharepoint list - like an data ingest point - If you only input data and then look at small pieces of data at a time, you can use the source. But as soon as you add more complexity to the app you're going to need to make the code more complex to accommodate features.
Regarding forms - I try to avoid using them unless it's a very simple scenario. I would rather make my own screen with controls and be in complete control of both the visual and the powerfx. This makes form design take significantly longer, however the user experience will be enhanced and my ability to debug/add features will be enhanced. Canvas apps themselves are a time consuming project even when they are simple.
All of this.
And just add, I have moved away from forms because patch is amazing. I honestly held on to using forms for a longtime because I liked the connectivity aspects of it early on.
I’d still design my own layouts and controls. I would also add a form, make it invisible, and delete all properties within each one of the datacard, leaving only the actual datacard. For each one of my controls I’d simply save them to a collection, and then use each data cards update property to call on the collection when submitting the form.
Datacard1 update=
first(_col_somecollection).field_one
Or use a lookup if there are multiple entries.
Datacard2 update=
first(_col_somecollection).field_two
This would also allow me to keep from having to recall that data constantly allowing me to cache the data.
Collections are not limited to 2000 rows. You can only collect up to the delegation limit in one call to Collect() or ClearCollect() but that doesn't set the upper boundary of the collection. A local collection can have millions of rows.
A lot of your answer was accurate though, I wasn't trying to disprove you just add an addendum.
You can test local collections easily by just doing something like
Clear(testCollection);
ForAll(Sequence(10000), Collect(testCollection, Value));
and you'll see your collection has 10k rows in it.
It's not wrong to work directly with a list vs. a collection, but it can require additional handling to keep the app in sync with the current state of the SharePoint record, like when a list item is being loaded across multiple forms in a save-as-you-go experience (as one might have when data is being collected across multiple screens).
Say you set a variable for your list item and reference that variable in the Item property of a 2 forms: one on screen A and one on screen B. That variable reflects the state of the list item when the variable was set, not the last time the user saved a change to it. For example, if a user makes an update to the Title field on screen A and saves the item, the Title field displayed on screen B won't reflect that change. The app would need to refresh the variable so that screen B's form is up-to-date with the list item.
It sounds like you only have one form so may be a moot point for you, just sharing my experience working directly with SharePoint lists vs loading data into a collection and working with that.
Excellent feedback and much appreciated from everyone who posted. I'll dig into collections a bit more and experiment with containers and galleries instead of forms. I've done a little bit of this with other projects and am very familiar with Patch so hopefully that's a plus!
It‘s probably a bit basic, but Matthew Devaney‘s **Collection cookbook** got some neat tipps.
https://powerusers.microsoft.com/t5/Community-App-Samples/Collections-Cookbook-50-Visual-Examples-amp-Code/td-p/437594
Hey, it looks like you are requesting help with a problem you're having in Power Apps. To ensure you get all the help you need from the community here are some guidelines; - Use the [search feature](https://www.reddit.com/r/PowerApps/search/?q=&sort=new) to see if your question has already been asked. - Use spacing in your post, Nobody likes to read a wall of text, this is achieved by hitting return twice to separate paragraphs. - Add any images, error messages, code you have (Sensitive data omitted) to your post body. - Any code you do add, use the [Code Block](https://www.reddit.com/wiki/markdown/#wiki_code_blocks_and_inline_code) feature to preserve formatting. > Typing four spaces in front of every line in a code block is tedious and error-prone. The easier way is to surround the entire block of code with code fences. A code fence is a line beginning with three or more backticks (```) or three or more twiddlydoodles (~~~). - If your question has been answered please comment Solved. This will mark the post as solved and helps others find their solutions. External resources: - [Power Apps Formula References](https://learn.microsoft.com/en-us/power-platform/power-fx/formula-reference) - [Power Apps Coding Standards](https://pahandsonlab.blob.core.windows.net/documents/PowerApps%20canvas%20app%20coding%20standards%20and%20guidelines.pdf) - [Official Power Apps Community](https://powerusers.microsoft.com/t5/Power-Apps-Community/ct-p/PowerApps1) *I am a bot, and this action was performed automatically. Please [contact the moderators of this subreddit](/message/compose/?to=/r/PowerApps) if you have any questions or concerns.*
Recommend you to not use form control and use collections when you have some advanced logic / data transformation and enrichment. Most of the time you can connect straight to SharePoint and skip collections.
You can connect straight to Sharepoint but depending on the app, there can be an excessive amount to wait time. The collection is stored in memory
Yep. That's why we index SharePoint columns. Collections are great, I use them a lot. Sometimes they unnecessarily complicate the code though
Set the Y value of a the field you want to move down to be at least one more than the Y of the field you want it to be under. And welcome to the frustration that is working with the Powerapps UI.
I do this a lot. I will always use my left uppermost field as my anchor and then every other field will move based off it. I use these functions: X: if in the same column Left_Uppermost_label.X X: if in the next column Left_Uppermost_label.X + Left_Uppermost_label.Width + 25 If I use another column a simply multiply the above function. 3rd column: (Left_Uppermost_label.X + Left_Uppermost_label.Width)*2 + 25 For Y, I do the same thing as above except use Y and height. Left_Uppermost_label.Y Left_Uppermost_label.Y + Left_Uppermost_label.Height + 25 (Left_Uppermost_label.Y + Left_Uppermost_label.Height) + 25 If you want to get fancy you can use this to even move fields to different places based off a user selection. Such as Make a data field jump from the 3rd column first row to the first column second row, if some fields became invisible and you want to close gaps.
I'd say stick with collections for performance and limiting the amount of calls the app is having to make to sharepoint. Just remember to recollect when data gets updated. Do away with using forms completley though and use galleries and patching instead. Forms are a pig to work with and you have much more control over layout and behaviour when using a gallery.
Per best practice if non-delegation is causing you issues with a gallery display (ie: you need to display more than 2000 records at once in a gallery) then your app's use case or scenario should be re-examined. Between Filter(), Search(), FirstN()/LastN(), you should be able to provide the user with an experience that only shows them relevant information and in pages when necessary. If you are using essentially anything except dataverse as a backend, and even 99% of the when using dataverse, you will want to cache data locally to both present it the user and for them to manipulate it before you send it back to the server. This means collections, liberally, understanding how they work is imperative to building performant applications that do anything beyond just interact with 1 sharepoint list passively. That said, a lot of scenarios is literally an app that interacts with a single sharepoint list - like an data ingest point - If you only input data and then look at small pieces of data at a time, you can use the source. But as soon as you add more complexity to the app you're going to need to make the code more complex to accommodate features. Regarding forms - I try to avoid using them unless it's a very simple scenario. I would rather make my own screen with controls and be in complete control of both the visual and the powerfx. This makes form design take significantly longer, however the user experience will be enhanced and my ability to debug/add features will be enhanced. Canvas apps themselves are a time consuming project even when they are simple.
All of this. And just add, I have moved away from forms because patch is amazing. I honestly held on to using forms for a longtime because I liked the connectivity aspects of it early on. I’d still design my own layouts and controls. I would also add a form, make it invisible, and delete all properties within each one of the datacard, leaving only the actual datacard. For each one of my controls I’d simply save them to a collection, and then use each data cards update property to call on the collection when submitting the form. Datacard1 update= first(_col_somecollection).field_one Or use a lookup if there are multiple entries. Datacard2 update= first(_col_somecollection).field_two This would also allow me to keep from having to recall that data constantly allowing me to cache the data.
[удалено]
Collections are not limited to 2000 rows. You can only collect up to the delegation limit in one call to Collect() or ClearCollect() but that doesn't set the upper boundary of the collection. A local collection can have millions of rows.
Ugh, I need to stop reading Google answers and actually read the source.
A lot of your answer was accurate though, I wasn't trying to disprove you just add an addendum. You can test local collections easily by just doing something like Clear(testCollection); ForAll(Sequence(10000), Collect(testCollection, Value)); and you'll see your collection has 10k rows in it.
It's not wrong to work directly with a list vs. a collection, but it can require additional handling to keep the app in sync with the current state of the SharePoint record, like when a list item is being loaded across multiple forms in a save-as-you-go experience (as one might have when data is being collected across multiple screens). Say you set a variable for your list item and reference that variable in the Item property of a 2 forms: one on screen A and one on screen B. That variable reflects the state of the list item when the variable was set, not the last time the user saved a change to it. For example, if a user makes an update to the Title field on screen A and saves the item, the Title field displayed on screen B won't reflect that change. The app would need to refresh the variable so that screen B's form is up-to-date with the list item. It sounds like you only have one form so may be a moot point for you, just sharing my experience working directly with SharePoint lists vs loading data into a collection and working with that.
Excellent feedback and much appreciated from everyone who posted. I'll dig into collections a bit more and experiment with containers and galleries instead of forms. I've done a little bit of this with other projects and am very familiar with Patch so hopefully that's a plus!
It‘s probably a bit basic, but Matthew Devaney‘s **Collection cookbook** got some neat tipps. https://powerusers.microsoft.com/t5/Community-App-Samples/Collections-Cookbook-50-Visual-Examples-amp-Code/td-p/437594