It is currently August 19th, 2022, 8:51 pm

reading local file with WebParser (more than 1 value)

Get help with creating, editing & fixing problems with skins
User avatar
balala
Rainmeter Sage
Posts: 14469
Joined: October 11th, 2010, 6:27 pm
Location: Gheorgheni, Romania

Re: reading local file with WebParser (more than 1 value)

Post by balala »

eclectic-tech wrote: July 19th, 2022, 3:57 am It is possible to read "Rainmeter.ini" only once and use StringIndex2 to return the desired values. If the desired value does not exist, a RegExp error will be logged, and you can use OnRegExpErrorAction to take any necessary steps.

This avoids reading the file multiple times and gives you options if the values do not exist.
Very good idea. I didn't realize this, but definitely works. So saved for future use...
Thanks a lot. :rosegift:
BananaJoe
Posts: 12
Joined: April 25th, 2022, 2:14 am

Re: reading local file with WebParser (more than 1 value)

Post by BananaJoe »

Very interesting approach with StringIndex2...maybe that was what I had been looking for all long. This definitely seems more resource-friendly. But I've questions to that solution:

These 3 are 'normal' child measures ([ReadingWindowY], [Reading KeepOnScreen], [ReadingLoadOrder]) next to the parent measure [ReadingFile] in our example?

If yes - shouldn't we leave off UpdateRate (like described here) then?
And if I initiate an update with !CommandMeasure, that would also mean that I only need [!CommandMeasure ReadingFile "Update"] (and no more [!CommandMeasure ReadingWindowY "Update"], [!CommandMeasure ReadingKeepOnScreen "Update"], [!CommandMeasure ReadingLoadOrder "Update"]), if I'm right...

Or are they a special form of a child measure? Or are they all actually parent measures and just using an earlier WebParser measure as the URL, where both have an RegExp on it?

Thank you in advance! :)
BananaJoe
Posts: 12
Joined: April 25th, 2022, 2:14 am

Re: reading local file with WebParser (more than 1 value)

Post by BananaJoe »

I also noticed that a Substitute= in the initial measure that reads the entire local file does nothing for this specific purpose. In the subsequent measures, which access the measure of the whole read file, separate Substitute= are needed instead.
Alternatively, one could place an additional measure in between, which has the value of the entire read file including the Substitute= changes. However, I'm not sure which variant would be more resource-saving.

After some testing I also noticed that in general there is still one basic case left unconsidered when parsing the local file:
The RegExp starts looking for a value at a certain section within the text file. If this value doesn't exist within the respective section, but (also) further down in the text file (within another section), then that value is used. So the reading process should stop at the beginning of a new section (beginning with an opening bracket "["), if it exists (otherwise at the end of the file).
Capturing the string ends with a carriage return, but this is only true if the value is found (that's good, but no matter where in the document it is).

As for the Rainmeter log (OnRegExpErrorAction=[!Log "..." Error]) - it happened to me that now and then only the custom message was displayed, but at last both the custom log and a RexExp matching error (-1) were displayed (I guess the latter is the normal behavior...).