Loading progress bar example

[JRaasumaa]

So after a bunch of headbanging I finally found a quick clean solution to create a loading bar when Patching an entire gallery with a ForAll to a SQL data source.

Step 1: Have a gallery with items in it that need to be patched to a data source.

Step 2: Create a button to patch your data source from the gallery items.

There are 2 commands in this button needs to make this work.

1st: Clear and Collect a Local Collection to load a new row value into each "loop" in the ForAll. 

ClearCollect(ProgressTable,{Progress:Blank()})

In this case I made a table called ProgressTable and called the 1 column I'm storing Progress. I also put a single Now() date time into it for a starter row (you don't necessarily need to use this or could patch a blank item) Changed to Blank() as it's faster.

2nd: The next command in the button is to run the ForAll to patch your data source, in the ForAll you will want to have a line added to the end of it (but within the context of the ForAll) that patches the ProgressTable with another line and it's Date/Time. 

ForAll(Gallery1.AllItems,(Patch... etc);Patch(ProgressTable,Defaults(ProgressTable),{Progress:Blank()}))

The Red partentheses are the entire ForAll, within the Blue is the patch you'd run to your data source, the Green is the second patch to add a new default row to the local collection.

Make sure to separate this second Patch from your initial one with a ; 

Your end result is 2 commands, a ClearCollect and the ForAll which patches 2 sources.

ClearCollect(ProgressTable,{Progress:Blank()});
ForAll(Gallery1.AllItems,(Patch... etc);Patch(ProgressTable,Defaults(ProgressTable),{Progress:Blank()}))

Step 3: Once the button is created with the 2 commands from Step 2 in it, make an object you'd like to show as a "progress" bar. In my case I did a rectangle with a 30 height and expected 200 width and another behind it that's slightly larger as a background border.

In the object you want as your progress bar you need to do a bit of math to figure out effectively how much of it to display based on what "row" the ForAll is actually patching (the progress). This is where the Gallery and Local Collection come into play.

In the smaller rectangle I have this code in the Width.

((CountRows(ProgressTable)/CountRows(Gallery1.AllItems))*200)+1

What this does is uses the percentage of rows completed as it's "progress". It does this looking at the Total Rows in the Gallery being Patched with the ForAll as well as the Current Total Row count of our Local Collection ProgressTable as it's actual "progress" since a new row gets added to the collection each time the ForAll loops (a way around the inability of a ForAll to UpdateContext a variable). 

The *200 is to give an overall percentage of the Width the bar will end up at, in this case I wanted the progress bar width to stop at 200. (I also added a +1 to it so the Rectangle always starts at 1 width so I guess technically the width ends up being 201)

Because this returns a number from 1 to 200 we can use that as the Width of the progress bar, meaning it will increase in size each time a new ForAll patched row is added!

What you end up with after some tweaking is a progress bar that can look like this:

The only other tricks I use are to hide this when the Gallery1 is fully collected. When the Save button is clicked I then Hide the Gallery1 and make Visible the "Saving..." text as well as the 2 rectangles I use to show the progress bar.

That's it!

Edit: I just tried changing the Now() to a blank and there was a noticable performance increase so I've since edited this to show Blank() instead of the Now()

[Meneghino]

Hi @JRaasumaa, could you please expand as to why you need the ForAll in the first place?

There may be some more efficient solutions that will make the upoading of data quicker.

[JRaasumaa · Accepted solution]

---

@Meneghino wrote:

Hi @JRaasumaa, could you please expand as to why you need the ForAll in the first place?

There may be some more efficient solutions that will make the upoading of data quicker.

---

In the locations we use the ForAll it's to allow for some conditional checking before Patching, in the case that's the slowest it's to decide which of 2 locations needs to be patched.

So after the ForAll there is an If Statement checking the specific line item row and if it meets certain criteria it patches to one SQL table, if it doesn't it patches it to another table.

In the example I showed above it's just one part of a big picture and I felt it was worth sharing 🙂

[Meneghino]

Ok, but it would seem more efficient to use a set based solution (as always with SQL): you could filter the source into two tables, one to be collected/mass patched to one SQL table and the other to the other SQL table.

Anyway, just a thought.  I have always managed to avoid ForAll as it is just disastrously slow with external connections.

[JRaasumaa]

---

@Meneghino wrote:

Ok, but it would seem more efficient to use a set based solution (as always with SQL): you could filter the source into two tables, one to be collected/mass patched to one SQL table and the other to the other SQL table.

Anyway, just a thought.  I have always managed to avoid ForAll as it is just disastrously slow with external connections.

---

It might seem more efficient to you but you also do not know the structure of our data and what the rest of the app is doing with the data storage within and on-site. From a mile high view it's easy to assume you know a better method but in this case the ForAll is the best current solution for us.

The structure and critique of our patching is not why I put this together, it's to help others using the ForAll function have a new way to show patching progress to their users.

I do appreciate your input though!

[Meneghino]

That is why I had suggested it would be more efficient to have look at the specifics directly.

I am always open for that when you like.

Have a good week-end.

[timl]

---

a new row gets added to the collection each time the ForAll loops (a way around the inability of a ForAll to UpdateContext a variable).

---

This is a really useful technique to work around the UpdateContext limitation within a ForAll loop. Thanks for sharing @JRaasumaa!

[Anonymous]

hi,
what can you use instead of "for all" that would make patching more efficient?
I'm interested in that,
thanks,