MattNY177 wrote: ↑April 5th, 2019, 12:37 am
Yes, this is exactly what I'm referring to. Say there's a measure that parses and downloads multiple large images from a dynamic URL to display in a photo slideshow. Now, let's say multiple Tiles use this measure by passing different URLs to gather those images.
For example, reloading the skin (or clicking a Refresh button) each slideshow tile would update the #ParentName# variable, then use !CommandMeasure to retrieve the latest images. The measure would reference the #ParentName#_URL to update the #ParentName#_slideshow meter(s) accordingly.
However, when the measure completes its parsing, if the #ParentName# has already been changed by subsequent tiles, there will be a mismatch when it goes to assign the values back to the meter. Is this assumption correct? If so, is there a better way to handle this process?
I see what you mean. Yes, there will be a mismatch, but
only if you update multiple tiles at once. If you update them synchronously/sequentially (meaning the next tile or meter is updated
only after the previous one completed its update), then I think it will solve the issue. I don't know if this suits your case, since they're large images and it would take a little bit to finish the process for each one of them, but if you use a single WebParser measure dynamically to achieve this, then going sequentially about it might be one of the few solutions available (apart from using multiple
#ParentNameNNN# variables or multiple WebParser measures along with their associated measures and meters).
Incidentally, I had a similar issue to yours in my Feeds skin, where I use a single WebParser measure to get a theoretically unlimited number of feeds and aggregate them to present them to the user, ticker style. I don't know if the way I approached this is of any help to you or if it suits exactly to your case, but what I did was create a "loop" of:
1. "update" the URL (if the URL was empty, exit the "loop", if not
!CommandMeasure the WebParser in step 2. using the updated URL)
2. use it to get the data in the WebParser measure
3. parse the data, process it and add it to the aggregator
4. go back to step 1. until the URLs were exhausted (i.e. encountered an "empty" URL)
This could be adapted to your workflow like this (if I correctly understood your process, that is):
1. slideshow tile 001 updates the
#ParentName# variable (if the tile number is "out of bounds", exit the "loop", if not
!CommandMeasure to 2.)
2. use
#ParentName#_URL to get the data in the WebParser measure
3. update the
#ParentName#_slideshow meter corresponding (or equal to) tile 001 with the corresponding image
4. go back to step 1. but for the next slideshow tile (i.e. tile 002, in this case), until the tile number is "out of bounds", aka the last one
So basically, you'd update tiles
one by one, in the
FinishAction of the WebParser measure, taking care to "move" to the next tile after updating the current one, also in the
FinishAction of the WebParser. Of course, you should be careful not to create an "infinite loop", since at 1. you trigger the WebParser and at 4. you go back at 1. with a new value, from inside the WebParser's
FinishAction.
This is something a bit tricky to properly explain in words, so if you think this can be applied in your case and want to see exactly how I did it, I could link to my skin suite to have a "sample framework" that you can adapt to your needs.