I'll say up front that this issue is a massive failure of how WebParser is coded. It is a long-standing problem, and not one that has a simple solution in today's environment.
Wow, thanks for the quick response. I was expecting a "sorry, you did something wrong, here's the problem in your approach" answer, but it seems that this is indeed a problem.
I completely understand the reason behind the need of NOT interpreting "waiting for an answer from the host" as "unreachable", and I agree this "failure" does have some... benefits. But it's still something that just isn't right.
That being said...
So you will need some other method of detecting a network failure, whether that be that your computer is not able to connect to the external resource, or that the external resource isn't answering. These are two very different conditions...
..................................
Now that I have laid out the challenge, give me an hour or two to chew on this and think about alternative solutions. I don't want to end up with some hideous Rube Goldberg solution, but this is not a particularly easy nut to crack.
I know it's tough to crack, as I spent a whole day trying to "workaround" it. I DO HAVE an alternative solution though, but that only fits my particular skin setup, not the problem in general.
I could base my checking for an external IP on the Ping plugin query (you may notice that I have a latency check below the IPs line in my network skin) by "invalidating" the WebParser based IP if the latency is maximum (that is, if the timeout is reached). Of course, I should synchronize those 2 checkings so that it wouldn't become disturbing for the internet connection, and it would also involve some "waiting" for the ping thingy to reach the timeout, so that it could give the thumbs up/thumbs down verdict on the WebParser check.
I thought about this "workaround" even when debugging the WebParser flaw, but being so stubborn, I wanted to do it the "right" way, using only the WebParser check. Something that would have helped was if I could check for the error thrown by WebParser - that way I would have known that something is wrong (e.g. If the IP is the same as before && WebParser throws error no. XXXX, bang some !SetOption stuff on the meter...)
If you come up with a better solution to the problem, then I would be glad to hear/see it - thank you again for being present and confirming my suspicions on the WebParser behaviour.
.................
On another note, I noticed a strange and sometimes disturbing "feature" of the IfCondition thing, and I wanted to ask you if this is intended (or "by design") behaviour : it seems to me that the IfCondition would only accept checking against numerical values, not strings. I know that there are IfMatch and IfEqual/IfBelow/IfAbove that can check against strings, but the IfCondition is the "complete" package (able to incorporate logical AND/OR/etc.) and it also has one GREAT advantage : IfConditionMode=1, which allows my skins to "react" instantly to changes in the measured values.
For example, in this piece of code
Code: Select all
[MS_PerfMon_BatteryDischargeRate]
Measure=Plugin
Plugin=PerfMon
PerfMonObject=BatteryStatus
PerfMonInstance=ACPI\PNP0C0A\1_0
PerfMonCounter=DischargeRate
PerfMonDifference=0
[MS_PerfMon_BatteryChargeRate]
Measure=Plugin
Plugin=PerfMon
PerfMonObject=BatteryStatus
PerfMonInstance=ACPI\PNP0C0A\1_0
PerfMonCounter=ChargeRate
PerfMonDifference=0
[MS_Power_BatteryPercent]
Measure=Plugin
Plugin=PowerPlugin
PowerState=Percent
IfCondition=(MS_PerfMon_BatteryDischargeRate>0)
IfTrueAction=[!SetOption MT_Power_Battery_Title Text "Battery charge rate: -[MS_PerfMon_BatteryDischargeRate] mWh"]
IfConditionMode=1
IfCondition2=(MS_PerfMon_BatteryChargeRate>0)
IfTrueAction2=[!SetOption MT_Power_Battery_Title Text "Battery charge rate: [MS_PerfMon_BatteryChargeRate] mWh"]
IfConditionMode=1
it would have been almost imposible (or quite difficult, using "workarounds") to reach the desired result (updating the MT_Power_Battery_Title meter on the fly according to the charge/discharge rate of the battery) if it weren't for the IfConditionMode=1 setting. Now imagine the MS_PerfMon_BatteryDischargeRate / MS_PerfMon_BatteryChargeRate measures that I'm checking were strings... I already tried, it looks like IfCondition doesn't like them, whether or not I put the string measures in [] or not...
Now if this is the intended behaviour, this would clear the things up for me - otherwise I'm thinking I'm missing something, or doing something wrong
Thanks again for your reply and for Rainmeter.
P.S. Oh, and to "spit it all out at once", it seems skins are sometimes "freezing" in a dimmed transition phase between the
Hide on mouse over states (hidden and showing). You may want to check that out, here it is the screenshot too (I know, a lot of CPU intensive skins, but I'm in the skin designing process, so all my desktop is a workshop for the time being, ha ha).
Notice the first skin (the upper one, with Toshiba Satellite....) is frozen in a dimmed state in the second screenshot. I have enabled Hide on mouse over on all the skins from the right side of the screen (those are my skins).