Updating skins using bangs to make them more responsive.

[jsmorley]

Added a new Tips & Tricks to show how to use some bangs to make skins more responsive to mouse actions:

http://docs.rainmeter.net/tips/update-with-bangs

[Wallboy]

Something I've noticed, is that when I set UpdateDivider=-1 on a WebParser measure and try to use [!UpdateMeasure measureName], it does not download the new resource. [!CommandMeasure measureName Update] does not work either while UpdateDivider=-1.

It seems UpdateDivider=-1 on a measure only allows it to update on a refresh one time and you can't manually update it with any command thereafter. This differs from UpdateDivider=-1 on a meter where !UpdateMeter works at any time.

Is this supposed to be like that for measures?

The only way I've been able to simulate "on command" behavior for WebParser is to set it to Disabled=1 and use a bang to enable the measure and then use [!CommandMeasure measureName Update]. And then a FinishAction disables the measure. However, if one has a really low Update rate, I would imagine that when the measure is enabled and inbetween downloading and parsing the resource before FinishAction is ran, Rainmeter probably trys to Update the measure again. I've heard that multiple updates to WebParser really quick could "freeze" it, so I wouldn't want this to happen.

UpdateDivider=-1 on the WebParser seems to be the solution to this problem, only it doesn't work like I thought it's supposed to. Not sure if I'm doing something wrong, or if there is anything way, let me know.

Thanks.

[jsmorley]

WebParser is a threaded plugin that to some extent controls itself. It is a little bit different than a normal measure like a Calc measure, that is just executed inside the "update loop" that controls the processing of a skin.

What WebParser has is a "counter" inside it, that is counting the times the measure is updated by the skin. When the value set for UpdateRate is reached, the plugin connects to the site, and the counter is reset.

So in a sense, the plugin is just always running. It sits, patiently waiting for the update of the measure to tell it to increment the counter that is tied to UpdateRate.

So each time the measure is updated, which is controlled like any other measure, with a combination of Update in [Rainmeter] and the UpdateDivider on the measure, the counter increases by one.

The default UpdateRate for WebParser is 600. So every 600 updates of the measure, it will connect to the site. With the default Update of 1000, and no UpdateDivider (default is 1) on the measure, that is every 600 seconds, or 10 minutes.

If you have an UpdateDivider on the measure, say UpdateDivider=5, then what happens is that every 5 skin updates, the measure tells WebParser to increment that internal counter by 1. That is why the formula to determine how often a site will be accessed is Update X UpdateDivider X UpdateRate.

That is why folks generally don't use any UpdateDivider on a WebParser measure, in most cases, that setting is just redundant to UpdateRate, and just requires more math to figure out the setting(s) you need, when the combination of Update in [Rainmeter] and UpdateRate alone is sufficient.

If you have UpdateDivider=-1 on a measure, then it is only updated once, when the skin is loaded or refreshed. What happens with WebParser is that the initial connection to the site is made once, and then never again. The internal counter is never told to increment again, so the plugin just patiently waits.

In order to then override the UpdateDivider=-1 and fire the measure, you would use !UpdateMeasure MeasureName in a bang. That is fine, but in the case of WebParser, all that does is cause the internal counter in the plugin to increment one time. If there is no UpdateRate on the measure, which would default to 600, you would have to fire !UpdateMeasure MeasureName 598 more times before it would connect to the site.

Now, what !CommandMeasure MeasureName "Update" does is tell the plugin to set that internal counter to whatever UpdateRate is, immediately causing the plugin to connect to the site, and then reset the counter.

However, the measure itself is still set to UpdateDivider=-1. It is not updating. So no new values would be returned from the plugin, which has cheerfully gone to the site and gotten data, but in a sense nobody is asking for it.

That is why you need to do both !CommandMeasure and !UpdateMeasure when UpdateDivider=-1 on the measure.

LeftMouseUpAction=[!CommandMeasure MeasureName "Update"][!UpdateMeasure MeasureOne][!UpdateMeter *][!Redraw]

[jsmorley]

As to this:

...I've heard that multiple updates to WebParser really quick could "freeze" it, so I wouldn't want this to happen.

It should be understood that the issue with "freezing" is only possible when the plugin actually connects to the site and downloads and parses data faster than it can keep up. This can only happen if:

1) You manually set a very low UpdateRate and have a combination of a very low Update and a very low (or no) UpdateDivider.

2) You flog the measure with [!CommandMeasure MeasureName "Update"] repeatedly in a very short period of time.

3) You "refresh" the skin repeatedly in a very short period of time, which causes the initial connection to the site to happen over and over again very quickly. This is the one that causes it 99.9% of the time, when someone is beating the refresh button like a rented mule while testing.

[Wallboy]

Aha! Very interesting read about how it works with WebParser, thanks! I was actually messing around with using both CommandMeasure and UpdateMeasure and when I had a UpdateMeasure bang BEFORE the CommandMeasure bang, Rainmeter would completely lock up. The other way around, it's working perfect.

As far as the freezing goes, I don't think I've ever ran into the problem yet. Though I do plan on having around 30 measures that will download a image to the Rainmeter-Cache that will be used in the skin. All 30 of those measures will have UpdateDivider=-1, but will be updated at the same time. Not sure if this will cause an issue with WebParser, but we'll see in time... I might also try cascading them with the FinishAction to run one after the other. Or I'll use a single measure to grab all the images, one at a time through a Lua script and just use DownloadFile and refer to the images that way. Already use that last method with another part of my skin and it works great.

[jsmorley]

Having a single WebParser measure that you set with DynamicVariables=1 and flog with:

[!SetOption MeasureName URL "SomeThingElse"][!CommandMeasure MeasureName "Update"][!UpdateMeasure MeasureName]

in order to download a bunch of images "all at once", does sound to me like it has the potential for issues. I would be tempted to have them cascade using FinishAction in some way. Using Lua won't be any real solution for this, as if you are sending a single WebParser "thread" out to the internet faster than it can keep up, it can cause problems no matter how you are controlling it.

However, having 30 WebParser measures to download 30 images is not going to be an issue. Fire at will... Each WebParser measure will create its own "thread", and they will have nothing to do with each other. They won't "stack up" or "conflict".

I suppose there is some theoretical limit to simultaneous connections in the Windows "network stack", but I suspect it is well above 30, and in any case Windows, and the Internet Explorer stub WebParser uses, is pretty good at managing this.

[Wallboy]

I have managed to use no Dynamic Variables anywhere in my skin yet. As far as a single measure grabbing all the images, what I do is

[!EnableMeasure measureName]
[!CommandMeasure measureName Update]
[!UpdateMeasure measureName]

within a script. This measure has a FinishAction that first disables the measure and then calls the script again. This script keeps track of which image I'm currently on through global variables. Each turn in the script I use [!SetOption measureName URL nextlink] to set the next URL. So each image is downloaded completely before it grabs the next one. Not sure what sort of issues I would run into with this, but it works thus far.