The Reset Gallery funciton doesn't save the highlighted Row, and instead the highlighted, selected item jumps to the top of the Gallery to the first record.
We want/need the Specific Gallery Item Highlighted to remain highlighted and only the underlying data to be refreshed.
How can we do this ?
Reset will reset a control to its Default value.
So, in your case, you will need to set the Default value on your Gallery. It would not be so bad as to (on the OnSelect) set a variable to ThisItem and then have your Default set to that variable.
See if that gets you anywhere and post back if not.
You could put (in your OnSelect of the Gallery) Set(selectedGalleryItem, ThisItem) and then set the Default property of the Gallery to selectedGalleryItem
This will keep the current item selected if you do a reset on the gallery. Of course, it would be interesting to note why you are resetting the gallery??
Keep in mind though, if this is a long listing of items, Reset on a Gallery will scroll the default item into view and this can cause some "jumping" in your Gallery.
Thank you, Randy, I will give that a try.
Reason why I am having to do this (please correct me if I am wrong, here) is because I am performing a Patch Update statement to SQL Azure. The Gallery needs to reflect the most up to date gallery, so it seems as though I first need to:
Refresh the SQL View so the new/modified data is refreshed and then
Reset the Gallery to display the new, refreshed data.
This will really depend on what you are using for a Items Source for you Gallery. If you are directly using the DataSource (or a filter thereof) then you do not need to refresh.
If you are trying to use a collection, then you will need to rebuild the collection each time (or patch it as well).
I try to avoid collections for this very reason. They have their place...but it's not every place!
Thank you, Randy.
I'm finding that I definitely have to do a refresh of the View.
I think you are correct that the Gallery Itself may not need to be Reset if it is based upon a View.
But the View itself must be refreshed, unfortunately.
It's too bad PowerApps doesn't handle/monitor data traffic so that a complete Refresh of the View is required.
This then leads one to move in the Collection direction. But you are correct, that has it's costs, too.
Yes, I believe that is correct (athough I've not confirmed), but it makes perfect sense. Since your view is, in itself, essentially a filter of a table, it is not directly connected in a way that updates to the base table (for which the view is based) would change the view that you've already loaded once. If you were able to Patch the View, then you would not have to refresh, but you can't Patch a view...only the underlying data tables.
This is actually almost exactly what people face with Collections. You can collect them yourself from data, but if you update the underlying data source, the Collection is not going to refresh, because it was based on a "load" of a view at the point of collection. If you want it (the collection) to refresh, you have to re-collect.
I believe this is exactly the same scenario you face with a SQL view. It is kind of a Collection that is based on the Table at the point that you "collect" it. Just because the table changes, doesn't mean that anything else will...until you execute the view again.