It is currently February 22nd, 2019, 3:20 pm

Preventing download error in log

Help with creating, editing & fixing problems with skins
User avatar
qwerky
Posts: 98
Joined: April 10th, 2014, 12:31 am
Location: Canada

Re: Preventing download error in log

qwerky » February 11th, 2019, 8:36 pm

balala wrote:
February 11th, 2019, 8:07 pm
Are you sure you get such error message? Because I don't get it for St. John's, NL. And no image is returned.
Log.png
This is very strange! I also do not get an error on that page, but the contents of msrGraphic1Icon is \AppData\Local\Temp\Rainmeter-Cache\weather.gc_5.ca, which is not an image; also the measure does correctly hide the meter.

That string does not appear in the page source, but the page source does not contain a daytime icon, just as expected, so I have no idea where that weather.gc_5.ca is coming from?
User avatar
balala
Rainmeter Sage
Posts: 7679
Joined: October 11th, 2010, 6:27 pm
Location: Gheorgheni, Romania

Re: Preventing download error in log

balala » February 11th, 2019, 8:48 pm

qwerky wrote:
February 11th, 2019, 8:36 pm
This is very strange! I also do not get an error on that page, but the contents of msrGraphic1Icon is \AppData\Local\Temp\Rainmeter-Cache\weather.gc_5.ca, which is not an image; also the measure does correctly hide the meter.

That string does not appear in the page source, but the page source does not contain a daytime icon, just as expected, so I have no idea where that weather.gc_5.ca is coming from?
Not sure, but doesn't even matter too much, I think. Important is that I get no error messages in the log, as you can see in the posted screenshot. The [msrGraphic1Icon] measure also returns something similar, but there is no error message.
User avatar
qwerky
Posts: 98
Joined: April 10th, 2014, 12:31 am
Location: Canada

Re: Preventing download error in log

qwerky » February 11th, 2019, 8:53 pm

So I tried Fredericton, NB, and this page is giving a matching error, presumably because the page is not showing a Tendency (the tendency should be either rising, falling, or steady). So it seems that the weather site is either inconsistent, or it is currently experiencing some difficulty. Since that error occurs earlier in the skin, it didn't even get to the msrGraphic1Icon.

Next I tried Halifax, NS, which again does not give an error, correctly hides the meter, and shows weather.gc_5.ca for msrGraphic1Icon. So I'm at a loss as to why some pages give the error, and others do not, even though they appear to be formatted the same way.
User avatar
balala
Rainmeter Sage
Posts: 7679
Joined: October 11th, 2010, 6:27 pm
Location: Gheorgheni, Romania

Re: Preventing download error in log

balala » February 11th, 2019, 9:05 pm

qwerky wrote:
February 11th, 2019, 8:53 pm
So I tried Fredericton, NB, and this page is giving a matching error, presumably because the page is not showing a Tendency (the tendency should be either rising, falling, or steady). So it seems that the weather site is either inconsistent, or it is currently experiencing some difficulty. Since that error occurs earlier in the skin, it didn't even get to the msrGraphic1Icon.

Next I tried Halifax, NS, which again does not give an error, correctly hides the meter, and shows weather.gc_5.ca for msrGraphic1Icon. So I'm at a loss as to why some pages give the error, and others do not, even though they appear to be formatted the same way.
No errors here, for none of the posted sites. Weird if you get one. :confused:
User avatar
qwerky
Posts: 98
Joined: April 10th, 2014, 12:31 am
Location: Canada

Re: Preventing download error in log

qwerky » February 11th, 2019, 9:49 pm

balala wrote:
February 11th, 2019, 2:17 pm
Also as jsmorley previously explained as reply to one of your own questions, probably would be great to add a & symbol to the measure name used into the URL option URL=#SiteURL#[&msrGraphicGroup], along with a DynamicVariables=1 option
But according to the Dynamic Cheat Sheet, "If you are "binding" a parent WebParser measure to a child measure with the URL option, you need the [], but not DynamicVariables." So are the '&' and 'DynamicVariables' really needed in the measure in this thread? ;-)

In the case discussed in the thread you mentioned, I ended up with FinishAction=[!SetOption msrHeaderAlertPage URL "#siteURL#[*&msrHeaderAlertURL*]"][!CommandMeasure msrHeaderAlertPage "Update"] as a solution, which does work, but I really don't understand what either the '&' or the two '*''s are actually doing. :oops:
User avatar
jsmorley
Developer
Posts: 18879
Joined: April 19th, 2009, 11:02 pm
Location: Fort Hunt, Virginia, USA

Re: Preventing download error in log

jsmorley » February 11th, 2019, 11:05 pm

The way that it works with WebParser is:

If you use [MeasureName] in a URL option in a WebParser measure, then the string information (captured) in the named parent and returned by a corresponding StringIndex number is used. DynamicVariables is not required. For this to work, it must refer to a WebParser parent measure, and there must be a matching StringIndex (captured) by the parent.

To directly use the string value of another measure in the URL option of a WebParser measure, the string value returned by the measure itself, not a single bit of information targeted by a StringIndex, you must use [&MeasureName] and DynamicVariables=1 is required. This will also allow you to use the string value of any measure in the URL, not just a WebParser measure.

Keep in mind that if if you have a parent measure that has a RegExp like:

RegExp=(?siU)<tag>(.*)</tag>

And the resource has in it:

<tag>Monday</tag>

Then the string value of the parent measure will be <tag>Monday</tag>. That is the point of regular expression, to "match" exactly what is asked for, while creating "indexes" for things that you (capture). The string value of the parent measure WILL NOT be Monday.

The string value returned by a child measure asking for StringIndex=1 from that parent WILL be Monday.

So this is fine as is:

Code: Select all

[msrGraphic1Icon]
Measure=WebParser
URL=#SiteURL#[msrGraphicGroup]
StringIndex=#GraphicIndexIcon#
Download=1
It presumably references a WebParser parent, and does so with a StringIndex. The fact that you are concatenating some string information to the front of it is not important. The fact that the Download=1 makes this at once both a "child" and a "parent" is not important.

Now, if you are creating a parent WebParser measure, and want to reference the string value of a "child" measure in the URL option, you will ALWAYS need to use [&MeasureName] and DynamicVariables=1. A child measure does not create (captures) or StringIndexes. If any WebParser measure sees [MeasureName] in the URL option, without the &, it ASSUMES and INSISTS that a StringIndex also be present.

I hope this helps some...

It can get a bit muddy since WebParser measures can be a mixture of "parent" and "child" OR "child" and "parent", all in the same measure.

Note that this is different than "binding" a WebParser child measure to a String meter. That will always just be MeasureName=MyMeasure, without any [square brackets], and DynamicVariables is not needed. You can only bind "child" measures to a String meter, so they will already have the properly resolved value.



As to [*MeasureName*] or #*Variable*#, those are "escaping" the measure or variable. What this means is that when used in a !SetOption or !SetVariable or !WriteKeyValue bang, the LITERAL, as in [MeasureName] and #Variable# will be set by the bang, not the RESOLVED VALUE of them.

This can be important if you are for instance changing the Text option of a string meter from:

Text=Today is [Measure1]

to:

Text=Today is [Measure2]

https://docs.rainmeter.net/manual/variables/#Escape

You don't want the current VALUE of [Measure2] to be hard-coded in the Text option, but the LITERAL "[Measure2]" so that later, when the meter is updated, IT will resolve the current value as needed.
User avatar
qwerky
Posts: 98
Joined: April 10th, 2014, 12:31 am
Location: Canada

Re: Preventing download error in log

qwerky » February 12th, 2019, 2:08 am

As always, thanks for a thorough reply. :)

So escaping, as in using something named literally, rather than its value, is clear. It is much like escaping characters in a regular expression or in a programming language such as C.

Now (thinking out loud) for WebParser measures, if the URL does not refer to another measure, then presumably it is a parent and refers to a page to be parsed, so there should be no StringIndex, and no '&' is required.

But, if the URL refers to another measure, then:
1. If the referred measure is a WebParser measure, and the referring measure contains a StringIndex, what is returned is the token referenced by the StringIndex. In this case, the '&' is not required.
2. If the referred measure is a WebParser measure, but the referring measure does not contain a StringIndex, what is returned is the entire string value of the referred measure. In this case also, the '&' is not required. Is this even possible?
3. If the referred measure is not a WebParser measure, then the referring measure should not contain a StringIndex, and what is returned is the string value of the referred measure. In this case, the '&' is, or is not, required? :???:

In the example:
FinishAction=[!SetOption msrHeaderAlertPage URL "#siteURL#[*&msrHeaderAlertURL*]"][!CommandMeasure msrHeaderAlertPage "Update"]
the msrHeaderAlertURL measure is both escaped (asterisks) and has an ampersand. So we want the URL to literally contain the text "msrHeaderAlertURL", and not the value of that measure. But why the ampersand?

In short, I'm still unclear as to what the '&' actually does, and when it is needed. :confused:
User avatar
jsmorley
Developer
Posts: 18879
Joined: April 19th, 2009, 11:02 pm
Location: Fort Hunt, Virginia, USA

Re: Preventing download error in log

jsmorley » February 12th, 2019, 2:57 am

qwerky wrote:
February 12th, 2019, 2:08 am
Now (thinking out loud) for WebParser measures, if the URL does not refer to another measure, then presumably it is a parent and refers to a page to be parsed, so there should be no StringIndex, and no '&' is required.

But, if the URL refers to another measure, then:
1. If the referred measure is a WebParser measure, and the referring measure contains a StringIndex, what is returned is the token referenced by the StringIndex. In this case, the '&' is not required.
2. If the referred measure is a WebParser measure, but the referring measure does not contain a StringIndex, what is returned is the entire string value of the referred measure. In this case also, the '&' is not required. Is this even possible?
3. If the referred measure is not a WebParser measure, then the referring measure should not contain a StringIndex, and what is returned is the string value of the referred measure. In this case, the '&' is, or is not, required? :???:
The long and the short of it is that if you are creating a URL option on any WebParser measure by referencing another measure, that will take one of two forms:

1) If you are referencing a measure that is acting as a "parent", and you are acting as a "child", which means you MUST have a StringInex option, then you don't need & or DynamicVariables=1. You are not creating an internet URL, but simply referencing and returning the value returned by the parent StringIndex.

This is the classic "parent / child" relationship fundamental to WebParser.

A "child" measure that references a "parent" measure in this way, but doesn't use a StringIndex, or in other words StringIndex=0, will use the entirety of the value of the parent measure. This would normally be used if you are creating a "child" that will then also be a "parent" by using a RegExp to parse the original parent's information, but doesn't itself go out to the internet. Then you would create "grandchildren" that reference those (captures).

It's a bit "inside baseball", but worth noting that it actually isn't the "child" measure going out and asking for the value from the parent on update, but the "parent" itself going out after it finishes its work, finding all of its "children", and forcing the value on them, based on StringIndex. This is why both UpdateRate and UpdateDivider are pointless on "child" measures.

2) If you are referencing the string value of any other measure (WebParser or not) then you MUST use & and DynamicVariables=1. This would be any time you are NOT using StringIndex to reference a particular (capture) from a parent.

Basically the & says "Don't look for a StringIndex and use a single (captured) parent value, but rather just use the string value of the referenced measure, as is." The DynamicVariables=1 says "Use the CURRENT value of the measure."

This is to create a "parent", while using an earlier "child" measure to obtain some or all of the internet URL needed. A "parent" that you expect to "got out" and get information from an external resource MUST ALWAYS have a fully qualified internet URI as the URL option.


Now, a WebParser measure can be both a "child" and a "parent" or a "parent" and a "child" at the same time, but I don't think I can explain that any better than I did in my earlier post. The only way to fully explain it is to give examples, and that would take pages of examples. There are lots of ways you can slice and dice this. In a general sense using StringIndex makes the measure a "child" and using RegExp or Download make the measure a "parent". But, you can do both...

qwerky wrote: In the example:
FinishAction=[!SetOption msrHeaderAlertPage URL "#siteURL#[*&msrHeaderAlertURL*]"][!CommandMeasure msrHeaderAlertPage "Update"]
the msrHeaderAlertURL measure is both escaped (asterisks) and has an ampersand. So we want the URL to literally contain the text "msrHeaderAlertURL", and not the value of that measure. But why the ampersand?
Based on a quick perusal of your code, I don't believe you need the & in that example...
User avatar
qwerky
Posts: 98
Joined: April 10th, 2014, 12:31 am
Location: Canada

Re: Preventing download error in log

qwerky » February 12th, 2019, 8:18 pm

Okay, time to massage the circulation back into your fingers, after all that typing... :D

Seriously, thanks again for the explanation; I think it is rather clear now. I also found this:
jsmorley wrote:
February 12th, 2019, 2:57 am
It's a bit "inside baseball", but worth noting that it actually isn't the "child" measure going out and asking for the value from the parent on update, but the "parent" itself going out after it finishes its work, finding all of its "children", and forcing the value on them, based on StringIndex. This is why both UpdateRate and UpdateDivider are pointless on "child" measures.
very interesting... one learns something every day! :thumbup: