Can't pass measure value to web parser

[Kotofanchik]

Still not clear though why the comparison with 0 is needed and why it wouldn't work without it...

According to my understanding now, comparison with zero says that the information of the parent web parser is already available and only after that can you start inserting the time stamp obtained from it to find the beginning of the required information. I don't know why it doesn't work without this. And I don’t understand why exactly after this you need to update the parent web parser again, but it works.
By the way, another parser RegExp matching error (-1) (Gismeteoinf_chrome01\Gismeteo.ini - [mStartHour])
But at the same time it works, that is, an error occurs at the first moment, since a time stamp is inserted into it where there is only one zero and that’s it, and it doesn’t find one and swears, but then the parent parser produces the correct stamp and I would like to update the child parser, but this did not work, but updating the parent parser is already working correctly and the child parser finds the right place.

[Yincognito]

According to my understanding now, comparison with zero says that the information of the parent web parser is already available and only after that can you start inserting the time stamp obtained from it to find the beginning of the required information. I don't know why it doesn't work without this. And I don’t understand why exactly after this you need to update the parent web parser again, but it works.
By the way, another parser RegExp matching error (-1) (Gismeteoinf_chrome01\Gismeteo.ini - [mStartHour])
But at the same time it works, that is, an error occurs at the first moment, since a time stamp is inserted into it where there is only one zero and that’s it, and it doesn’t find one and swears, but then the parent parser produces the correct stamp and I would like to update the child parser, but this did not work, but updating the parent parser is already working correctly and the child parser finds the right place.

I see, thanks for explaining it. Well, if it works, then it's all good. Yes, the error is because during the 1st request, [mFullDate] doesn't yet have a value that can be used in [mStartHour] (since they both retrieve data at the exact same time, as functions of the WebParser parent), and by the 2nd request it already has the [mFullDate] value from the 1st request.

[Kotofanchik]

I’m almost done and I’m wondering if it’s possible to hide some of the skin’s errors in the log? It seems that they arise at the first moment, when the data has not yet been received.

[Yincognito]

I’m almost done and I’m wondering if it’s possible to hide some of the skin’s errors in the log? It seems that they arise at the first moment, when the data has not yet been received.

Apart from unticking showing errors and warnings, I don't think there is, since like you probably already realize, they are related to the fact that at the moment of skin load / refresh, the "fact time" isn't yet retrieved from the web resource (the latter isn't instantaneous, it takes a bit of time to connect / download / read either the local file or the online site).

[Kotofanchik]

Apart from unticking showing errors and warnings, I don't think there is, since like you probably already realize, they are related to the fact that at the moment of skin load / refresh, the "fact time" isn't yet retrieved from the web resource (the latter isn't instantaneous, it takes a bit of time to connect / download / read either the local file or the online site).

Is there any way to disable the display of errors in the skin itself? I disabled some errors this way, but those were errors of lack of stringindex in child measures. I don’t know how to turn off others. I would like to disable regexp and time errors.

[Yincognito]

Is there any way to disable the display of errors in the skin itself? I disabled some errors this way, but those were errors of lack of stringindex in child measures. I don’t know how to turn off others. I would like to disable regexp and time errors.

Apart from the LogSubstringErrors option in WebParser (which only tackles some of the regex errors) and obviously providing a valid initial Timestamp value (e.g. a dummy one just for the start) in the skin, nope.

[Kotofanchik]

Apart from the LogSubstringErrors option in WebParser (which only tackles some of the regex errors) and obviously providing a valid initial Timestamp value (e.g. a dummy one just for the start) in the skin, nope.

Oh, I'll try the dummy time stamp

[balala]

I’m wondering if it’s possible to hide some of the skin’s errors in the log?

Is there any way to disable the display of errors in the skin itself?

Apart from Yincognito's reply, actually it is, but I wouldn't recommend it. An error should be fixed instead of hide it.
If you want to hide / disable them, uncheck the appropriate checkbox (Error, Warning, Notice and / or Debug) in the Rainmeter Log window:

Log.png

[Kotofanchik]

Apart from the LogSubstringErrors option in WebParser (which only tackles some of the regex errors) and obviously providing a valid initial Timestamp value (e.g. a dummy one just for the start) in the skin, nope.

Is there an example of how this is done? I couldn’t do it myself. Apparently it’s necessary to create a variable or several in a file from the current measure or meter? How to do it? It didn't work out for me. I'm doing something wrong. Then, how do I assign the value of a variable to measure?
The skin had to be redone because it turns out that the information update time is not always in the range 00:00, 03:00, 06:00 and so on (it was convenient since the clock data also goes) But it turns out there are also 00:30, 01: 30 in some cases. And there were more measures with errors at the initial moment.

[Yincognito]

Is there an example of how this is done? I couldn’t do it myself. Apparently it’s necessary to create a variable or several in a file from the current measure or meter? How to do it? It didn't work out for me. I'm doing something wrong. Then, how do I assign the value of a variable to measure?
The skin had to be redone because it turns out that the information update time is not always in the range 00:00, 03:00, 06:00 and so on (it was convenient since the clock data also goes) But it turns out there are also 00:30, 01: 30 in some cases. And there were more measures with errors at the initial moment.

Simple example, based on the DOW code earlier - it's up to you to get the idea and implement the approach in your actual skin:

Code: Select all

[Variables]
DummyDate=June 15, 2024

[Rainmeter]
Update=1000
AccurateText=1
DynamicWindowSize=1
BackgroundMode=2
SolidColor=0,255,0,255

[Date]
Measure=WebParser
URL=https://time.is/en/UTC
RegExp=(?siU)<div id="dd" .*>.*, (.*)</div>
StringIndex=1
UserAgent=Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/126.0.0.0 Safari/537.36
DynamicVariables=1

[DOW]
Measure=Time
TimeStampFormat=%B %d, %Y
TimeStamp=[Date]
Format=%A
DynamicVariables=1

---Meters---

[DOWText]
Meter=String
MeasureName=DOW
Text=DOW: %1

Now, as you can see in the Rainmeter log, the above code will throw 2 TimeStampFormat errors on load / refresh, since the TimeStamp option of the [DOW] measure doesn't yet have a valid value until the [Date] measure retrieves it from the site and the [DOW] measure updates to reflect the change. However, if you do TimeStamp=#DummyDate# in the [DOW] measure and add FinishAction=[!SetOption DOW TimeStamp "[Date]"][!UpdateMeasure DOW][!UpdateMeter DOWText][!Redraw] to the [Date] measure, there will be no more such errors on load / refresh, because the value of the timestamp be a valid dummy date right from the start, being replaced with the actual date once the webparser retrieves it.

So basically, you need to correct the TimeStamp option not having a valid value before it's set from the site. How to do it, is your choice, the above is just one way of approaching this. You could even write it directly as TimeStamp=June 15, 2024 (or whatever other valid value, according to whatever timestamp format you use) and not use a variable at all, as long as you set it to the actual value afterwards, from the FinishAction of the webparser parent (or whatever other measure is retrieving the actual date).