SCR wrote: ↑August 1st, 2020, 3:35 pm
Wow, you sure have been busy. I downloaded your new Weather.com skin, I like to make the changes to the WeatherComJSONVariables.inc there so I have a way to check my skin, copied all the needed *.inc files in to my skin and everything worked perfectly with one exception. I had to add two measures to my SpecialMeasures.inc file. The
[@CurrentVisibilityDistance] was showing a result of 10.0000. I passed it through a calc measure and it's now showing 10.
Here is the code I added:
Code: Select all
[Visibility]
Measure=WebParser
URL=[@CurrentConditionsParent]
StringIndex=18
RegExpSubstitute=1
Substitute=#CommonSubstitute#
[VisibilityDistance]
Measure=Calc
Formula=Visibility
Thanks to you and everyone else that has contributed to this on going project. Obviously it's something I would never be able to do. I appreciate all your hard work.
Using a Calc measure like:
Code: Select all
[MeasureRoundDistance]
Measure=Calc
Formula=Round([@CurrentVisibilityDistance],0)
DynamicVariables=1
Will give you complete control over how many, or none, decimal places you want to show.
I see NO good reason to "overload" the measure [@CurrentVisibilityDistance] with that [Visibility] child measure you have. I would lose that measure entirely. When you "overload" a measure in the skin .ini, you are going to want to use either a String or Calc measure to manipulate the string or number values returned, or to add "tests" like IfCondition or IfMatch. There is just no good reason to prompt WebParser to return the child measure value once again. It's already there and available in [@CurrentVisibilityDistance].
The danger in what you are doing there is that I may change the StringIndex number that returns the current visibility distance from the JSON tomorrow, and the point of all this is that is transparent to you and your skin. If you start going after the RegExp in the skin itself, that can only lead to tears.
Note: Be aware that unless you play a trick where you Disabled=1 this Calc measure, and only !EnableMeasure or !EnableMeasurGroup it as a OnFinishAction on the WebParser parent measure, you might get at least one initial error in the log, something like "syntax error" or "extra operation in formula". In general, if you are using
Calc or
Time measures that reference the child measures from WebParser, you are going to want to disable them until WebParser is finished, or you can get a few errors.
I think you can simply add
Disabled=1 to the Calc measure, and add
Group=Parents or
Group=Times to it as well. I already have OnFinishAction's on the WebParser parents that enables those groups when they are done.
Code: Select all
[MeasureRoundDistance]
Measure=Calc
Formula=Round([@CurrentVisibilityDistance],0)
DynamicVariables=1
Group=Parents
Disabled=1
Note: While using Round() in a Calc measure will restrict the number of decimal places, it is "no more than", not "exactly". What I'm getting at is that if you use anything other than "0" as the rounding factor, say "1", a string of "10.000" will return "10", not "10.0", and in fact a string of "10.009" will still return just "10". If you really want a consistent number of decimal places, again, say "1', you would probably want a String measure instead:
Code: Select all
[MeasureRoundDistance]
Measure=String
String=[@CurrentVisibilityDistance]
DynamicVariables=1
RegExpSubstitute=1
Substitute="^([\d]+)(\.)([\d]{1}).*$":"\1\2\3","^([\d]+)$":"\1.0"
Now that is "truncating", not "rounding", (or adding a ".0" to the end of a whole number) but it is the only way I can see to get a consistent number of decimal places other than zero for a value that could in theory be 10.000 / 10.9 / 10.09 / 10.009. If the concern is consistency in "width / real estate", this is how I would go.
Throwing away all decimal places is probably fine with a units of measure of "e" (Imperial) as I think visibility is always returned in whole miles. When you are using "m" (Metric) I think it is far more likely that you will get a number that contains a fractional number of kilometers, as presumably it is converted from miles using a formula in the API, and that is pretty much never going to result in whole kilometers. So it's up to you how you handle this. It depends a bit on the design of your skin (width) and your target audience... I'd be tempted to show at least one decimal place.
This behavior by the API is a bit puzzling really. I don't really understand why they return a string of "10.000", when that is clearly just 10. While I consider this bad programming, I'd be less confused by it if Wind Speed did the same thing, but it doesn't... mph and km/h are both in whole numbers.
I may try to rewrite the skin or just wait and see if xxenium fix the regexp in the near future.
