Help: Rainmeter Skins • Re: How to delay the firing of IfCondition?

I think the problem is that at the first moment webparser returns zero. And although the value then changes to the desired value, other than zero, IfCondition has already seen this zero and no longer works.
In the test skin, you can comment out the desired url10 to test different weather options.
you can also manually set the length of the day directly or from a file by commenting out the desired

Code:

[mdurmcalc]Measure=Calc;Formula=[mdurm]Formula=911

if I manually set the length of the day in minutes from 0 to 1440, then everything works. And when parsing, the same incoming numbers are stopped at the number 0; if 0 had not appeared for a short time at the first moment, then everything would have worked in my opinion. but I couldn't get around this problem.

You correctly identified the problem and presented a test skin for it. Typically, this kind of issues are dealt with by starting with the "misbehaving" measures disabled and then enabling them after the data is retrieved, so that whatever IfConditions they contain, they'll react only to a data filled contents of the said measures. There are multiple ways to do this, given that Rainmeter has a Disabled option for measures, as well as bangs to disable or enable measures (followed by updating them afterwards) at will, see the manual. One way to do it would be:What I did was first group the last 2 measures together so that I could manipulate them easier. Then, I disabled the group when starting to make the request from the site (i.e. I swapped the UpdateDivider and UpdateRate values so I could use OnUpdateAction to trigger the disabling), and a WebParser measure's FinishAction to enable the group when finally retrieving the data.

Notes:
- swapping the UpdateDivider and UpdateRate values will require preceding [!CommandMeasure mNow "Update"] with a [!UpdateMeasure mNow], if you'll ever want to use the former to retrieve the data "manually" at some point, since the initial disabling is triggered by a "regular measure update" as oppposed to a "WebParser retrieval update" (see here for details on each of them)
- you could probably set UpdateDivider=-1 for the last 2 measures, since their data really changes only after a WebParser request anyway
- alternatively, if you know you'll never use [!CommandMeasure mNow "Update"], you could just use Disabled=1 on the last 2 measures and get rid of the now unnecessary UpdateDivider, UpdateRate and OnUpdateAction lines in the 1st measure, since the "null" value of a WebParser measure that's bothering your code is typically only present initially, at skin load or refresh time, and not afterwards
- be aware that the skin will only react with enabling the last 2 measures above when successfully retrieving the requested data; to do this or something else when the retrieval has issues, you can check the other action options of WebParser, besides the already mentioned FinishAction

Statistics: Posted by Yincognito — Yesterday, 9:50 pm

---