Variable RegEx quantifiers in WebParser RegExp option

[Yincognito]

Any reason why this works:

Code: Select all

[Variables]
Feed=someRegExExpression

[aaa]
Measure=Calc
Formula=0

[somemeasure]
Measure=Plugin
Plugin=WebParser
Url=someURL
StringIndex=someIndex
RegExp='(?siU)(?:#Feed#){[aaa]}(#Feed#)'
StringIndex2=someIndex2
DynamicVariables=1

(having a [measure] as {quantifier} in a RegEx expression)

but this doesn't:

Code: Select all

[Variables]
Feed=someRegExExpression
aaa=0

[somemeasure]
Measure=Plugin
Plugin=WebParser
Url=someURL
StringIndex=someIndex
RegExp='(?siU)(?:#Feed#){#aaa#}(#Feed#)'
StringIndex2=someIndex2
DynamicVariables=1

(having a #variable# as {quantifier} in a RegEx expression)?

The variables work fine for me outside the {} quantifiers markers, but it seems they fail to do it inside the {}...
Anyone happens to experience this as well? The only way I could explain it is that the measure also has the string value...maybe WebParser likes that inside the {}?

[jsmorley]

I'm not sure what is going on. You certainly can use a #VarName# in the {range quantifier} of a regular expression. I used just that here:

https://forum.rainmeter.net/viewtopic.php?p=117192#p117192

A [SectionVariable] uses the string value of a measure, and #VarName# is just always a string, so I don't see any difference there.

P.S. The single quotes are not needed. Rainmeter just throws away quotes, single or double, at the beginning and end of an option value.

[Yincognito]

I found out why this happens. It's because the variable is truly dynamic (I'm trying to dynamically modify the RegExp option to "jump" to another feed). In the 2nd code section I posted, the #aaa# variable will work, because it's truly static. What happens is that if I make this truly dynamic (i.e. also modifying it in another section of the code), then the RegExp option fails to deliver the expected result.

I noticed this before, as well. The RegExp option seems to not like to be modified dynamically. Try with a "truly" dynamic variable for yourself and let me know if it happens for you as well. In my skin code, as soon as I made another static #bbb# variable and tried to use it, it worked.

P.S. The single quotes are not needed. Rainmeter just throws away quotes, single or double, at the beginning and end of an option value.

Yes, I know, they are put there for the sake of uniformity, considering I also have double quotes inside the string.

[jsmorley]

https://forum.rainmeter.net/viewtopic.php?f=111&t=16210

[Yincognito]

I'm not sure what you meant by that...is that WebParser works with dynamic variables or that one of the "Some important things to understand" prevents me from achieving the desired result?

...or is this what you were referring to?

3) If you dynamically change an option on a "child" WebParser measure that depends on a "parent" measure, (like StringIndex for instance) you MUST use !CommandMeasure with "Update", targeting the "parent" WebParser measure. The values of child WebParser measures are a function of the parent measure, and are only updated when the parent is. You should never use !CommandMeasure on a "child" measure, as it won't do anything.

If that's so, why should I update the parent measure to be able to change the quantifier, if the contents of what I'm parsing stays the same? This doesn't make any sense, since updating the parent measure would mean I could get a different number of feeds, thus my quantifier will get the wrong feed! I understand the technicalities involved that don't allow certain methods, but how can I make it work while keeping the same information in the parent WebParser measure? And yes, the measure where I'm using the dynamic quantifier is a child measure.

One more thing...does 3) means that chosing to use a changeable [measure] as a quantifier also won't work unless updating the parent measure? Cause that would leave me with no choice than to revert to my "old" way of using string measures instead of WebParser ones (which has some disadvantages over the WebParser method)...

Thanks for answering, as always

[jsmorley]

Yes, I am referring to this:

3) If you dynamically change an option on a "child" WebParser measure that depends on a "parent" measure, (like StringIndex for instance) you MUST use !CommandMeasure with "Update", targeting the "parent" WebParser measure. The values of child WebParser measures are a function of the parent measure, and are only updated when the parent is. You should never use !CommandMeasure on a "child" measure, as it won't do anything.

What I'm saying is that WebParser child measures actually do petty much nothing on their own. They are in effect "populated" by the parent measure when it updates.

So if you have something dynamic in the child measure, it will only return a new value from WebParser if you !CommandMeasure the parent measure to force it to update itself, and thus the children.

While I can't test your example, I'm sure your issue must be related to this.

[Yincognito]

Ok then, thanks.