The way that it works with WebParser is:
If you use
[MeasureName] in a URL option in a WebParser measure, then the string information (captured) in the named parent and returned by a corresponding StringIndex number is used. DynamicVariables is not required. For this to work, it must refer to a WebParser parent measure, and there must be a matching StringIndex (captured) by the parent.
To directly use the string value of another measure in the URL option of a WebParser measure, the string value returned by the measure itself, not a single bit of information targeted by a StringIndex, you must use
[&MeasureName] and
DynamicVariables=1 is required. This will also allow you to use the string value of any measure in the URL, not just a WebParser measure.
Keep in mind that if if you have a parent measure that has a RegExp like:
RegExp=(?siU)<tag>(.*)</tag>
And the resource has in it:
<tag>Monday</tag>
Then the string value of the parent measure will be
<tag>Monday</tag>. That is the point of regular expression, to "match" exactly what is asked for, while creating "indexes" for things that you (capture). The string value of the parent measure WILL NOT be
Monday.
The string value returned by a child measure asking for StringIndex=1 from that parent WILL be
Monday.
So this is fine as is:
Code: Select all
[msrGraphic1Icon]
Measure=WebParser
URL=#SiteURL#[msrGraphicGroup]
StringIndex=#GraphicIndexIcon#
Download=1
It presumably references a WebParser parent, and does so with a StringIndex. The fact that you are concatenating some string information to the front of it is not important. The fact that the Download=1 makes this at once both a "child" and a "parent" is not important.
Now, if you are creating a parent WebParser measure, and want to reference the string value of a "child" measure in the URL option, you will ALWAYS need to use [&MeasureName] and DynamicVariables=1. A child measure does not create (captures) or StringIndexes. If any WebParser measure sees [MeasureName] in the URL option, without the
&, it ASSUMES and INSISTS that a StringIndex also be present.
I hope this helps some...
It can get a bit muddy since WebParser measures can be a mixture of "parent" and "child" OR "child" and "parent", all in the same measure.
Note that this is different than "binding" a WebParser child measure to a String meter. That will always just be MeasureName=MyMeasure, without any [square brackets], and DynamicVariables is not needed. You can only bind "child" measures to a String meter, so they will already have the properly resolved value.
As to
[*MeasureName*] or
#*Variable*#, those are "escaping" the measure or variable. What this means is that when used in a !SetOption or !SetVariable or !WriteKeyValue bang, the LITERAL, as in [MeasureName] and #Variable# will be set by the bang, not the RESOLVED VALUE of them.
This can be important if you are for instance changing the Text option of a string meter from:
Text=Today is [Measure1]
to:
Text=Today is [Measure2]
https://docs.rainmeter.net/manual/variables/#Escape
You don't want the current VALUE of [Measure2] to be hard-coded in the Text option, but the LITERAL "[Measure2]" so that later, when the meter is updated, IT will resolve the current value as needed.