HelloAndGoodbye wrote:jsmorley, would there be any way to fix this to prevent log spam or is it currently unfixable?
By the way, the skin seems to be missing a background image so I'll update the file with the background image and a new feature as well (hopefully today).
It will vary a bit depending on how the skin is set up, but what I see from that error log is that some WebParser measure is returning some value, let's say a number like 3 as an example.
Then there is an Image meter somewhere that has ImageName=[SomeMeasure].png, or even just ImageName=[SomeMeasure], as the .png is assumed if there is no extension specified.
Since on the first update the value of [SomeMeasure] is "", that turns into ImageName=.png, which obviously isn't going to work.
As soon as the WebParser parent measure is finished, and it populates any child measures dependent on it, then that will change to ImageName=3.png, and all is well, assuming 3.png is located on the local drive where you specify.
I'm not sure there is a good way to eliminate the initial errors that isn't just more trouble than it is worth. At a high-level, what you want is to have some "placeholder" image set as the ImageName on the meters, or even just don't have an ImageName option at all on them when the skin is first loaded, and then with a FinishAction on the parent WebParser measure, set the ImageName on the meters to what they really should be, but only after the parent WebParser measure is "finished". That way you can either have some "N/A" image to start with, or just no image at all, and there will be no errors generated.
Depending on the complexity of the skin, and how many image meters are involved, this could turn into a lot of work and code. There is some point where I would probably just live with a handful of errors in the log that only happen once when the skin is first loaded or refreshed.