That action and bang is supposed to change the latitude to the longitude when you left-click the skin. Instead, nothing happens. I've also tried using a variable and changing that and a section variable in the StringIndex option (both [Measure] and [&Measure]), but again, nothing.
Last edited by JelleDekkers on June 20th, 2020, 1:44 pm, edited 1 time in total.
"Child" WebParser measures are not independent measures. They are entirely controlled, and their data populated, by their "parent" WebParser measure.
So it does nothing to update a child measure, the measure isn't "asking" the parent measure what the value of a particular StringIndex is, the parent is reading the options on the child, and when the parent is updated itself, it populates the child measures appropriately.
JelleDekkers wrote: ↑June 20th, 2020, 1:11 pm
Ah, my bad. I forgot about that. It would make things so much easier if it were possible though
It's just not possible though, and not even desirable. The beauty of the "parent / child" approach is that the child measures take almost zero resources, as they are never independently "updated". All the work is done by the relatively far fewer parent measures.
Think of the parent and all its many, many children as one single thing. a child measure is just part of the functionality of the parent.
JelleDekkers wrote: ↑June 20th, 2020, 12:39 pm
The title says it all.
[...]
That action and bang is supposed to change the latitude to the longitude when you left-click the skin. Instead, nothing happens. I've also tried using a variable and changing that and a section variable in the StringIndex option (both [Measure] and [&Measure]), but again, nothing.
To add to what jsmorley said, if you want to avoid needlessly polling the site again by using [!CommandMeasure mWebParser "Update] for every little change of a dynamic variable, you might want to store the affected info into String measures instead of WebParser ones. Personally, I use this method in both my feeds and weather skins, where the entire content over which I want to "iterate" using an index is stored in a String measure, where I can use dynamic variables freely without worrying that I might poll the site too often and get "unexpected" susprises.
Yincognito wrote: ↑June 24th, 2020, 11:58 am
To add to what jsmorley said, if you want to avoid needlessly polling the site again by using [!CommandMeasure mWebParser "Update] for every little change of a dynamic variable, you might want to store the affected info into String measures instead of WebParser ones. Personally, I use this method in both my feeds and weather skins, where the entire content over which I want to "iterate" using an index is stored in a String measure, where I can use dynamic variables freely without worrying that I might poll the site too often and get "unexpected" susprises.
I ended up just making two child measures and using nested variables to get my desired result