[Bug] Rainmeter trying to open a non existent png file that hasn't been called

[eclectic-tech]

Thank you for your response, but I still don't understand why my code is still warning for missing png file after doing a code deep clean up, I couldn't find any instruction for such an operation. Skin is much faster an smooth now than posted here down those days when first post.

You can check it out the latest version if you want: https://forum.rainmeter.net/viewtopic.php?t=41394

As Yincognito pointed out, this is due to a change in how Rainmeter handles images. This happens regularly with weather skins that display condition images before the Webparser measures obtain the necessary data.

EDIT: This will not help in your case, since it is happening when you access multiple folders and placing this image in every folder is not an option.

If the error message refers to .png file as missing, one option that will prevent the log messages, is to create a blank .png file in the folder that Rainmeter is reporting the error.

Here is a blank file you can save as ".png" to prevent the error messages:

[Yincognito]

Thank you for your response, but I still don't understand why my code is still warning for missing png file after doing a code deep clean up, I couldn't find any instruction for such an operation.

From my experiance, this could happen in one or both of these two cases:
- if the image for a valid image path doesn't exist
- if the path for such an image is not valid
For the first variant, eclectic-tech already provided a solution.
For the second variant, the issue is a bit more complex. It could be because the said path is not yet initialized in the code at the time of access (e.g. a blank variable, etc.), the said path is not properly set up in the code at the time of access (e.g. the variable holding the path parses to an unresolved formula, some other unresolved variables that are not yet set up properly, etc.), or the said path is set up properly only after the time of access (e.g. the need of access happens earlier than you get the chance to set up the path, etc). By "access" I mean the moment when the meter actually wants to read the image specified by the path.

As for debugging, you know best what exactly happens in the code when you click a folder / icon (because it's then that the errors are listed in the log) , but some relatively easy way to help you with the issue would be to just !Log the value of the image path / name option you're using to diplay such images, e.g.:

Code: Select all

[SomeImage]
Meter=Image
ImageName=#@##SomeOtherVariable#.png
OnUpdateAction=[!Log "#@##SomeOtherVariable#.png"]
DynamicVariables=...

Basically, if such a !Log doesn't list a valid path to be used (e.g. "C:\SomeFolder\SomeImage.SomeImageExtension") and instead lists other invalid variants (e.g. ".png" or "#SomeUnresolvedVariable(s)#" or "(1+#SomeVariableInAnUresolvedFormula#)" and so on), then you know you have to fix it one way or another.

[Jaime Méndez]

For the first variant, eclectic-tech already provided a solution.

I think first variant may be the case, but the problem is that I'd have to place an empty file in all PC directories and subdirectories in order to get rid of the bug. The Skin is a directory browser that reads files and folders everywhere and represents its icon files and thumbnails pictures.
The path certainly exists since no subdirectory is created by the time skin is browsing directories and subdirectories.