Can't pass measure value to web parser

[Kotofanchik]

While I was struggling with errors in the log and reducing the load, I broke the work again and copied and pasted the wrong thing. So the previous archive is also very buggy

[Yincognito]

While I was struggling with errors in the log and reducing the load, I broke the work again and copied and pasted the wrong thing. So the previous archive is also very buggy

No worries, I didn't test any of the previous archives you posted (not my style to look for the needle in the haystack and correct every line of code from user skins), I only looked at the code for reference in answering your questions.

Quick questions, out of curiosity:
1) what you really want to display in your skin is the data starting from the <forecast valid> that's greater or equal to <fact valid>, right?
2) if yes, why did you check for the hour in <forecast valid> being greater than 0 in the beginning of the skin development?
3) does cur_time matter for your skin or is it irrelevant?

[Kotofanchik]

No worries, I didn't test any of the previous archives you posted (not my style to look for the needle in the haystack and correct every line of code from user skins), I only looked at the code for reference in answering your questions.

Quick questions, out of curiosity:
1) what you really want to display in your skin is the data starting from the <forecast valid> that's greater or equal to <fact valid>, right?
2) if yes, why did you check for the hour in <forecast valid> being greater than 0 in the beginning of the skin development?
3) does cur_time matter for your skin or is it irrelevant?

1 - Yes.
2 - This was done in order to check that the parser data was already correct; I specifically chose the beginning of the capture in numbers so that it could be compared. I tried to replace it with FinishAction. But this option began to freeze after one normal update.
3 - no. I wanted to use it in the first versions, but in some cities there are completely unrealistic dates and times that differ from the current time by several days..

[Yincognito]

1 - Yes.
2 - This was done in order to check that the parser data was already correct; I specifically chose the beginning of the capture in numbers so that it could be compared. I tried to replace it with FinishAction. But this option began to freeze after one normal update.
3 - no. I wanted to use it in the first versions, but in some cities there are completely unrealistic dates and times that differ from the current time by several days..

1 - Thanks for confirming it.
2 - Oh, I see, but that shouldn't be needed.
3 - Yeah, that happens for me too, I guess that's actually when data was updated on the site for the city.

[Kotofanchik]

2 - Oh, I see, but that shouldn't be needed.

What can replace such a check? I can’t do it without her. Tell us the principle.
As I understand it, FinishAction= is not always processed correctly. Otherwise, how can we explain that it works during the initial update, but then freezes after a while? I thought FinishAction does roughly the same thing as comparing the parser's capture to zero if the start of the capture is aimed at a number greater than zero

[Kotofanchik]

One of the versions works for me with two updates to the parent parser. It works without complaints from users except in one city, where there may be no hourly data at night, or rather they are available 4 hours after the data validation time, and my version cannot bypass this. The new version, which first captures the entire hourly forecast, can, but there are already three! updates to the initial parser, without which the subsequent parser does not begin checking. I hope this is true or does not disturb the site, since perhaps the parsers specially cache the site for at least a few seconds, otherwise I don’t understand why it was done that only restarting the parent parser activates the child ones. Or maybe the parser does not read the site itself if the site survey data has not changed?

[Yincognito]

Or maybe the parser does not read the site itself if the site survey data has not changed?

Exactly, see here for details or if you want to change the default behavior, but be aware that changing the default behavior will actually request data from the site (instead of using the cache) every Update x UpdateDivider x UpdateRate milliseconds (which is the formula for the frequency at which a WebParser parent measure "updates"):
https://docs.rainmeter.net/manual/measures/webparser/#ForceReload

What can replace such a check? I can’t do it without her. Tell us the principle.

Yes, you can do without it, there's no need for such a check. For example, the st2.txt response in the last .7z you uploaded here has <fact valid="2024-06-25T00:00:00"...>, so a zero hour, but that doesn't mean that the response itself was not correct (since it's a perfectly valid .xml with all the data you need in it), it only means that you should display data from <forecast valid="2024-06-25T00:00:00"...> onwards, that's all. If the response itself was not "correct" as per your RegExp, then the regex would automatically fail to match anything, since the response would most likely be either nothing if not connected to the internet, or some shorter "cannot retrieve data, blah blah blah" formatted .xml. You'll get a few harmless regex errors in the log and all the values of the WebParser child measures will be empty (or what "default" values you choose them to be if they are empty, via Substitute). Therefore, no need for such a check, it will all fail silently (well, except for the log, which would let you know that there were parsing issues, obviously).

[Kotofanchik]

I'm starting to think that the skin cannot be implemented with hiding the meter. If you read all the watches, then the minimum from what I came across is 19 groups of watches. 8 groups for the previous day, eight for the current day and three more for tomorrow. The previous day is rarely present, but sometimes it is present. Now we take 4 groups, this is a third of the skin in volume, if we take 19, then the volume will more than double. Already now the skin is working very hard, difficulties in work are visible. It will probably put an unrealistic load on the processor.

[Yincognito]

I'm starting to think that the skin cannot be implemented with hiding the meter. If you read all the watches, then the minimum from what I came across is 19 groups of watches. 8 groups for the previous day, eight for the current day and three more for tomorrow. The previous day is rarely present, but sometimes it is present. Now we take 4 groups, this is a third of the skin in volume, if we take 19, then the volume will more than double. Already now the skin is working very hard, difficulties in work are visible. It will probably put an unrealistic load on the processor.

Yes, the maximum number of potential forecasts (and the visual elements representing each of them) can indeed be large. Personally, I always thought that displaying only a few of them (e.g. only 8 for a day, in your case, or even just 1 if needed), and then scrolling to see the others completely solves the issue.

[Kotofanchik]

!SetOption does not want to assign a timestamp to measure. assigns to meter but does not want to measure

Code: Select all

[!SetOption "metertest" "text" "[H[&CN1C]]"][!SetOption Measure CN1m TimeStamp "[H[&CN1C]]"][!UpdateMeasure CN1m][!SetOption Measure CN1 TimeStamp "[H[&CN1C]]"][!UpdateMeasure CN1]

The time value was definitely there, it was clear that the time was correct. But the assignment by !SetOption does not occur; the previous value from DummyDate remains.
log: !SetOption: Skin "2024-06-30T12:00:00" not found (Gismeteoinf_chrome02n\GismeteoColor.ini)
If you don't use Dummy date, then everything works correctly

Code: Select all

[CN1m]
Measure=Time
TimeStampFormat=%Y-%m-%dT%H:%M:%S
;TimeStamp=#DummyDate#
TimeStamp=[H[&CN1C]]
Format=%Y-%m-%dT%H:%M:%S
DynamicVariables=1