[BUG?] Image Dimensions Not 0 For Non Existing Image

[Yincognito]

Prerequisites:
- an image0.jpg image file in the @Resources folder of the skin

Skin:

Code: Select all

[Variables]
Index=0

[Rainmeter]
Update=1000
DynamicWindowSize=1
AccurateText=1

---Measures---

[Index]
Measure=Calc
Formula=#Index#
DynamicVariables=1

---Meters---

[Text]
Meter=String
Y=0R
FontColor=255,255,255,255
FontSize=14
AntiAlias=1
SolidColor=0,0,0,255
Text="Click Here To Toggle Between An Existing And a Non Existing Image (Image Width = [Test:W])"
LeftMouseUpAction=[!SetVariable Index (1-#Index#)][!UpdateMeasure Index][!UpdateMeter Test][!UpdateMeter Text][!Redraw]
DynamicVariables=1

[Test]
Meter=Image
Y=0R
ImageName="#@#image[Index].jpg"
DynamicVariables=1

Expected Behavior:
- when toggling to image1.jpg on left clicking the text, the width of the meter should be 0, since only image0.jpg exists

Actual Behavior:
- when toggling to image1.jpg on left clicking the text, the width of the meter stays the same as before, despite the meter not displaying anything

Questions:
- is this the expected behavior or is this a bug?
- if it's not a bug, is this related to image caching in Rainmeter?
- if it's not a bug, how can I get the expected behavior?
- if it's a bug, would fixing this affect backward compatibilty?

This skin is a simplified version of the skin here (which attempts to show a "default" image if the image associated with a media track does not exist, and to show the said image if it does exist).

[Brian]

This was quite a curious bug that has existed for a long time (maybe since the beginning). Honestly, I cannot believe this hasn't come up before (maybe it has, but I don't remember it).

The good news is, the image was properly being "disposed of" internally, so no memory issues were present. The only problem was the meter's dimensions (if not defined) would not be reset if there was a problem opening the image file.

I believe this to be fixed for the next beta. Logically, this shouldn't cause a backwards compatibility issue - however, due to the nature of the bug, there could be an issue in a very small amount of skins that might take advantage of this bug. I personally can't think of a situation this could be used, but that doesn't mean some skin isn't creating some "place holder" type of area in their skin in case an image isn't loading properly.

Anyway, one small note is that this does not effect any image meter that specifically defines a W and/or H. Those values will remain if an image cannot be opened.

-Brian

PS - I re-added the error message for images that cannot be loaded. It was somehow removed when we switched over to D2D rendering.

[Yincognito]

This was quite a curious bug that has existed for a long time (maybe since the beginning). Honestly, I cannot believe this hasn't come up before (maybe it has, but I don't remember it).

Yeah, that's me: I boldly discover bugs that no man has gone... I mean discovered before.

I believe this to be fixed for the next beta. Logically, this shouldn't cause a backwards compatibility issue - however, due to the nature of the bug, there could be an issue in a very small amount of skins that might take advantage of this bug. I personally can't think of a situation this could be used, but that doesn't mean some skin isn't creating some "place holder" type of area in their skin in case an image isn't loading properly.

Indeed, this is what I meant - skins that might take advantage of this bug, or rather the behavior in those cases. Thanks for looking into it and fixing it.

Anyway, one small note is that this does not effect any image meter that specifically defines a W and/or H. Those values will remain if an image cannot be opened.

For sure, this makes sense.

PS - I re-added the error message for images that cannot be loaded. It was somehow removed when we switched over to D2D rendering.

Hm...I wish you wouldn't have done that. One of the nice things about this "bug" is that it failed silently, without any error messages to alarm the regular user. I understand the purpose of this and the fact that the user needs to have control and all that, but there are some "errors" or "warnings" that are expected, taken into account and harmless in some skins, and it would be nice if there was a way to not cause "panic" for the regular user in those cases, by "hiding" some of them. Anyway, I was aware of the risk (i.e. "fixing" the error message as well) when letting you know of the bug, so it is what it is. Thanks again.

[jsmorley]

Just create a 0 x 0 sized image file to use when you want to do this. I resist that it is a good practice to create an actual file not found error and depend on that. To each his own of course, but an error is an error. The point of the errors in the log is to alert the user / author that something they thought was working, isn't. I for one am generally not in favor of hiding errors. There are some exceptions to that, when LogSubstringErrors in WebParser or the IgnoreWarnings setting in ActionTimer make sense.

[Yincognito]

Just create a 0 x 0 sized image file to use when you want to do this.

Ok, but how would I be able to use this in this specific scenario (checking if an image file exists)? Since I can't know in advance the name of the non-existing image file, not to mention a 0 x 0 image would not "cover" anything and when using it in a "default image or actual image" scenario the other image will be entirely visible. Or maybe I'm missing something?

Yep, I understand the pros and cons of displaying errors in the log. Thing is, they don't cover the possibility of something the author knew it wasn't working (and was ok with that, since it played a role in the behavior of the skin), and it isn't. Well, I guess a note by the author somewhere in the skin (or the log) that a certain error is to be expected, so that the user doesn't panic and stop using the skin as a result, would be another "workaround", since an error showing toggle is a bad idea. Just saying, I'm not particularly concerned by this, but regular users might be (even when they shouldn't), in the cases I referred to above.

[jsmorley]

Ok, but how would I be able to use this in this specific scenario (checking if an image file exists)? Since I can't know in advance the name of the non-existing image file, not to mention a 0 x 0 image would not "cover" anything and when using it in a "default image or actual image" scenario the other image will be entirely visible. Or maybe I'm missing something?

Hmm.. You have what sounds on the surface like two sorta conflicting requirements here. You want to detect that an image doesn't exist, but you then want to "cover" up something using it?

As to detecting if an image exists, if I really needed that, I'd be tempted to use Lua, OR use either cmd.exe or PowerShell in a RunCommand measures to detect and act.

1.jpg

[Yincognito]

Hmm.. You have what sounds on the surface like two sorta conflicting requirements here. You want to detect that an image doesn't exist, but you then want to "cover" up something using it?

Yeah, my bad, I mixed things up - disregard my previous question.

As to detecting if an image exists, if I really needed that, I'd be tempted to use Lua, OR use either cmd.exe or PowerShell in a RunCommand measure to detect and act.

Yes, that's true. The image meter method was the simplest and the fastest way of doing that - that's why I used it. You know, similar to how you can use FreeDiskSpace measures to "detect" if a drive / partition exists by checking if its total space is 0 - that kind of stuff.

[jsmorley]

Yes, that's true. The image meter method was the simplest and the fastest way of doing that - that's why I used it. You know, similar to how you can use FreeDiskSpace measures to "detect" if a drive / partition exists by checking if its total space is 0 - that kind of stuff.

That is entirely fair...

[jsmorley]

Code: Select all

[Rainmeter]
Update=1000
DynamicWindowSize=1
AccurateText=1
OnRefreshAction=[!CommandMeasure MeasureFileExists "Run"]

[Variables]

[MeasureFileExists]
Measure=Plugin
Plugin=RunCommand
Parameter=IF EXIST "#@#Images\lampoon.jpg" (echo FOUND!) ELSE echo NOT FOUND!

[MeterExists]
Meter=String
MeasureName=MeasureFileExists
FontSize=15
FontWeight=400
FontColor=255,255,255,255
SolidColor=47,47,47,255
Padding=5,5,5,5
AntiAlias=1
Text=lampoon.jpg is %1

[Yincognito]

Code: Select all

[Rainmeter]
Update=1000
DynamicWindowSize=1
AccurateText=1
OnRefreshAction=[!CommandMeasure MeasureFileExists "Run"]

[Variables]

[MeasureFileExists]
Measure=Plugin
Plugin=RunCommand
Parameter=IF EXIST "#@#Images\lampoon.jpg" (echo FOUND!) ELSE echo NOT FOUND!

[MeterExists]
Meter=String
MeasureName=MeasureFileExists
FontSize=15
FontWeight=400
FontColor=255,255,255,255
SolidColor=47,47,47,255
Padding=5,5,5,5
AntiAlias=1
Text=lampoon.jpg is %1

Nice one liner without the need for a batch file. I'll keep this in mind for the more general purpose of checking if a file of any type exists. Just for reference - I'm sure it's trivial, but how would a Lua script for this look like? It'll be faster than the RunCommand variant, right?