It is currently March 28th, 2024, 7:32 pm

Generate Automatic WeatherCode from IP address in use

Get help with creating, editing & fixing problems with skins
User avatar
jsmorley
Developer
Posts: 22628
Joined: April 19th, 2009, 11:02 pm
Location: Fort Hunt, Virginia, USA

Re: Generate Automatic WeatherCode from IP address in use

Post by jsmorley »

JamX wrote: October 6th, 2019, 4:45 pm TRUE.!


ByTheWay: is it possible to see or check how often an update takes place. (Time)
in the log file I only see the initial loading of the skin
You could add a FinishAction=[!Log "I just updated"] action to the parent(s).
User avatar
JamX
Posts: 207
Joined: October 4th, 2019, 2:46 pm

Re: Generate Automatic WeatherCode from IP address in use

Post by JamX »

if I add
FinishAction=[!Log "I just updated"]
to the 3rd webparser, where do I find the log file?

I already found it. In the log in the rainmeter program itself :?
User avatar
balala
Rainmeter Sage
Posts: 16110
Joined: October 11th, 2010, 6:27 pm
Location: Gheorgheni, Romania

Re: Generate Automatic WeatherCode from IP address in use

Post by balala »

jsmorley wrote: October 6th, 2019, 3:28 pm You can't really set a WebParser measure to only measure "once",
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?
User avatar
balala
Rainmeter Sage
Posts: 16110
Joined: October 11th, 2010, 6:27 pm
Location: Gheorgheni, Romania

Re: Generate Automatic WeatherCode from IP address in use

Post by balala »

JamX wrote: October 6th, 2019, 4:45 pm TRUE.!


ByTheWay: is it possible to see or check how often an update takes place. (Time)
in the log file I only see the initial loading of the skin
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
Now add the [!UpdateMeasureGroup "UpdateDateTime"] bang to the FinishAction option of the WebParser measure, beside the existing bangs. For instance:

Code: Select all

[MeasureIPLocation]
...
FinishAction=[!EnableMeasure MeasureWeatherCodeLocationRSS][!CommandMeasure MeasureWeatherCodeLocationRSS "Update"][!UpdateMeasureGroup "UpdateDateTime"]
If you now are visualize (with a String meter) the date and time returned by these measures, you can see there the date and time of last update.
User avatar
jsmorley
Developer
Posts: 22628
Joined: April 19th, 2009, 11:02 pm
Location: Fort Hunt, Virginia, USA

Re: Generate Automatic WeatherCode from IP address in use

Post by jsmorley »

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?
Yes, you could do something like this:

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]
Then you can manually control the update of the WebParser measure with UpdateDivider, instead of UpdateRate.

The key to this is that a WebParser parent measure goes out to the remote resource every UpdateRate * UpdateDivider measure updates...
User avatar
balala
Rainmeter Sage
Posts: 16110
Joined: October 11th, 2010, 6:27 pm
Location: Gheorgheni, Romania

Re: Generate Automatic WeatherCode from IP address in use

Post by balala »

jsmorley wrote: October 6th, 2019, 8:29 pm The key to this is that a WebParser parent measure goes out to the remote resource every UpdateRate * UpdateDivider measure updates...
Yeah, this is clear. But is there a difference if UpdateRate is set to -1, or UpdateDivider?
User avatar
jsmorley
Developer
Posts: 22628
Joined: April 19th, 2009, 11:02 pm
Location: Fort Hunt, Virginia, USA

Re: Generate Automatic WeatherCode from IP address in use

Post by jsmorley »

balala wrote: October 6th, 2019, 8:43 pm Yeah, this is clear. But is there a difference if UpdateRate is set to -1, or UpdateDivider?
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/
User avatar
balala
Rainmeter Sage
Posts: 16110
Joined: October 11th, 2010, 6:27 pm
Location: Gheorgheni, Romania

Re: Generate Automatic WeatherCode from IP address in use

Post by balala »

jsmorley wrote: October 6th, 2019, 10:30 pm UpdateRate doesn't support a setting of -1.
:o Didn't know this, but based on the explanation, definitely makes sense. :o
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. :thumbup:
User avatar
jsmorley
Developer
Posts: 22628
Joined: April 19th, 2009, 11:02 pm
Location: Fort Hunt, Virginia, USA

Re: Generate Automatic WeatherCode from IP address in use

Post by jsmorley »

balala wrote: October 7th, 2019, 7:05 am :o Didn't know this, but based on the explanation, definitely makes sense. :o
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. :thumbup:
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, (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.
User avatar
balala
Rainmeter Sage
Posts: 16110
Joined: October 11th, 2010, 6:27 pm
Location: Gheorgheni, Romania

Re: Generate Automatic WeatherCode from IP address in use

Post by balala »

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.
Ok, thanks for the clarifications. Much clearer...