You could add a FinishAction=[!Log "I just updated"] action to the parent(s).
It is currently April 25th, 2024, 5:18 pm
Generate Automatic WeatherCode from IP address in use
-
- Developer
- Posts: 22629
- Joined: April 19th, 2009, 11:02 pm
- Location: Fort Hunt, Virginia, USA
Re: Generate Automatic WeatherCode from IP address in use
-
- Posts: 207
- Joined: October 4th, 2019, 2:46 pm
Re: Generate Automatic WeatherCode from IP address in use
if I add
I already found it. In the log in the rainmeter program itself
to the 3rd webparser, where do I find the log file?FinishAction=[!Log "I just updated"]
I already found it. In the log in the rainmeter program itself
-
- Rainmeter Sage
- Posts: 16169
- Joined: October 11th, 2010, 6:27 pm
- Location: Gheorgheni, Romania
Re: Generate Automatic WeatherCode from IP address in use
Even if this a little bit late, I don't entirely see why a WebParser measure couldn't be set to update only once, then later update it only when the previous measure is updated as well. This might be done by adding an UpdateDivider=-1 option to the subsequent parent WebParser measures. In this case to [MeasureWeatherCodeLocationRSS] and [MeasureWeatherRSS].
I agree this is not a common and usual approach, but not impossible is, I think. Is it?
-
- Rainmeter Sage
- Posts: 16169
- Joined: October 11th, 2010, 6:27 pm
- Location: Gheorgheni, Romania
Re: Generate Automatic WeatherCode from IP address in use
Or beside jsmorley's recommendation, you could add two, never updated Time measures, to get the date and time, then update these when the WebParser measure is updated. In a such case doesn't matter if the WebParser measure is updated by the UpdateRate, or "manually", through a !CommandMeasure bang.
This is what I thought to: add the following two measure to the code:
Code: Select all
[MeasureDate]
Measure=Time
Format=local-date
UpdateDivider=-1
Group=UpdateDateTime
[MeasureTime]
Measure=Time
Format=local-time
UpdateDivider=-1
Group=UpdateDateTime
Code: Select all
[MeasureIPLocation]
...
FinishAction=[!EnableMeasure MeasureWeatherCodeLocationRSS][!CommandMeasure MeasureWeatherCodeLocationRSS "Update"][!UpdateMeasureGroup "UpdateDateTime"]
-
- Developer
- Posts: 22629
- Joined: April 19th, 2009, 11:02 pm
- Location: Fort Hunt, Virginia, USA
Re: Generate Automatic WeatherCode from IP address in use
Yes, you could do something like this:balala wrote: ↑October 6th, 2019, 5:46 pm Even if this a little bit late, I don't entirely see why a WebParser measure couldn't be set to update only once, then later update it only when the previous measure is updated as well. This might be done by adding an UpdateDivider=-1 option to the subsequent parent WebParser measures. In this case to [MeasureWeatherCodeLocationRSS] and [MeasureWeatherRSS].
I agree this is not a common and usual approach, but not impossible is, I think. Is it?
Code: Select all
[WebParser]
Measure=WebParser
URL=file://#CURRENTPATH#Test.html
RegExp=(?siU)<item>(.*)</item>
StringIndex=1
UpdateDivider=-1
UpdateRate=1
[MeterOutput]
Meter=String
MeasureName=WebParser
FontSize=11
FontWeight=400
FontColor=255,255,255,255
SolidColor=47,47,47,255
Padding=5,5,5,5
AntiAlias=1
LeftMouseUpAction=[!UpdateMeasure WebParser]
The key to this is that a WebParser parent measure goes out to the remote resource every UpdateRate * UpdateDivider measure updates...
-
- Rainmeter Sage
- Posts: 16169
- Joined: October 11th, 2010, 6:27 pm
- Location: Gheorgheni, Romania
Re: Generate Automatic WeatherCode from IP address in use
Yeah, this is clear. But is there a difference if UpdateRate is set to -1, or UpdateDivider?
-
- Developer
- Posts: 22629
- Joined: April 19th, 2009, 11:02 pm
- Location: Fort Hunt, Virginia, USA
Re: Generate Automatic WeatherCode from IP address in use
UpdateRate doesn't support a setting of -1.
There would be no reason to change it to support that. UpdateDivider=-1 with UpdateRate=1 will do the same thing that UpdateRate=-1 with UpdateDivider=1 would do.
The key to understanding this is understanding the basic mechanism of how a WebParser parent works.
The measure itself is just like any measure. It is updated once every skin Update, and can be controlled with UpdateDivider and Disabled/Paused and acted upon with !UpdateMeasure and !EnableMeasure/!UnpauseMeasure and all that, just like any measure.
However the guts of the measure, under the covers, is controlled by an internal UpdateRate counter. That starts at zero and is incremented by 1 on each measure update, and when it reaches the value set for UpdateRate, it resets to zero. When the value of this counter is zero, it goes out to the remote resource. UpdateRate must be a positive number from 1 to the maximum 4294967295 for a 32bit integer.
The only way to override this UpdateRate / counter is to use the !CommandMeasure action with a value of "Update". Using !UpdateMeasure on the measure itself only forces one extra increment to the counter, which won't have the effect of forcing it to go out to the remote resource. It will just move it one update closer to that.
That is why I suggested using UpdateDivider=-1 and UpdateRate=1 to have the measure only go out to the remote resource once. That way it will do that, fire once when the skin is loaded / refreshed. However, it can also be manually forced to update with !UpdateMeasure, since that will cause one increment of the UpdateRate counter, which is set to "1", and so it will immediately hit that, reset and fire. If you don't need to ever manually fire it, just set UpdateDivider=-1 and don't worry about UpdateRate.
https://docs.rainmeter.net/tips/webparser-updaterate/
-
- Rainmeter Sage
- Posts: 16169
- Joined: October 11th, 2010, 6:27 pm
- Location: Gheorgheni, Romania
Re: Generate Automatic WeatherCode from IP address in use
Didn't know this, but based on the explanation, definitely makes sense.
But one more question, in this case: what if I still set the UpdateRate to -1? In a such case the measure uses the default value for this option (UpdateRate=600) or what?
BTW, thanks for the explanations.
-
- Developer
- Posts: 22629
- Joined: April 19th, 2009, 11:02 pm
- Location: Fort Hunt, Virginia, USA
Re: Generate Automatic WeatherCode from IP address in use
It seems like UpdateRate=-1, which is not really supported, might in fact have the effect (more or less) of behaving like UpdateDivider=-1 does.balala wrote: ↑October 7th, 2019, 7:05 am Didn't know this, but based on the explanation, definitely makes sense.
But one more question, in this case: what if I still set the UpdateRate to -1? In a such case the measure uses the default value for this option (UpdateRate=600) or what?
BTW, thanks for the explanations.
This is due to how the C++ code is written. The value for UpdateRate is a UINT data type, which is a 32bit unsigned integer, and can't be negative. The intent is that UpdateRate is a number from 1 to 4294967295.
When you pass a negative number to a UINT, that creates a technical error condition, and the number will "wrap around" to the largest value supported by the data type. That is 4294967295, or put another way, if Update=1000, that would be 136 years.
So in effect it might work ok, as you are likely to restart the skin sometime in the next 136 years, (Starfleet will insist on it) but I'd be very leery of depending on the generosity of an error condition. At this time, I'd recommend against using UpdateRate=-1. For one thing, I can't be certain that this behavior will be consistent across other measures and plugins that use the UpdateRate approach.
The most reliable approach to having a WebParser measure "fire once" is to use UpdateDivider=-1 and then don't worry about UpdateRate.
-
- Rainmeter Sage
- Posts: 16169
- Joined: October 11th, 2010, 6:27 pm
- Location: Gheorgheni, Romania
Re: Generate Automatic WeatherCode from IP address in use
Ok, thanks for the clarifications. Much clearer...jsmorley wrote: ↑October 7th, 2019, 12:34 pm It seems like UpdateRate=-1, which is not really supported, might in fact have the effect (more or less) of behaving like UpdateDivider=-1 does.
This is due to how the C++ code is written. The value for UpdateRate is a UINT data type, which is a 32bit unsigned integer, and can't be negative. The intent is that UpdateRate is a number from 1 to 4294967295.
When you pass a negative number to a UINT, that creates a technical error condition, and the number will "wrap around" to the largest value supported by the data type. That is 4294967295, or put another way, if Update=1000, that would be 136 years.
So in effect it might work ok, as you are likely to restart the skin sometime in the next 136 years, but I'd be very leery of depending on the generosity of an error condition. At this time, I'd recommend against using UpdateRate=-1. For one thing, I can't be certain that this behavior will be consistent across other measures and plugins that use the UpdateRate approach.