[#Variable] is unknown. Is this a bug?

[RicardoTM]

So, the skin I'm having problems with is much more complex that this example I'm gonna show you, but it perfectly demonstrate the problem.

I'm making a proportional/scalable/dynamic skin (hence the variables format) and when I'm trying to set a escaped variable it shows this error on the log:
Formula: "[#Variable]" is unknown: (...)

I made this skin that replicates the error:
It resizes when scrolling on it, the target is to keep the corners proportional while doing it.

Code: Select all

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

[Variables]
Size=200
Scale=1
scaleMin=1
scaleMax=5
scaleIncrement=0.5
aspectRatio=(16/9)
Width=([#*Size*]*[#*Scale*])
Height=([#*Width*]/[#*aspectRatio*])
Corners=([#*Width*]*(1/20))
Theme=Theme1

[measureMeter]
measure=String
String=[#Theme]
IfMatch=Theme1
IfMatchAction=[!SetVariable Corners "([#*Width*]*(1/10))"]
DynamicVariables=1

[shapeMeter]
meter=shape
shape=rectangle 0,0,[#Width],[#Height],[#Corners] | strokewidth 0
MouseScrollUpAction=[!SetVariable Scale (Clamp(([#Scale]+[#scaleIncrement]),[#ScaleMin],[#ScaleMax]))][!UpdateMeter *][!Redraw]
MouseScrollDownAction=[!SetVariable Scale (Clamp(([#Scale]-[#scaleIncrement]),[#ScaleMin],[#ScaleMax]))][!UpdateMeter *][!Redraw]
DynamicVariables=1

As you can see, it works fine, if you scroll up/down it resizes correctly even though it shows the error I mentioned earlier on the log.

So the question is, what is causing this error? To me it has to do with the escaped variable but this is what happens:

(I'm talking about the IfMatchAction)
If you don't escape [#Width] then it stops being dynamic (which means the corners stop being proportional when resizing it).
If you escape it once [#*Width*] then it works fine but shows the error Formula: "[#Width]" is unknown: ([#Width]*(1/10)).
If you escape it twice [#**Width**] then it stops working at all (to me this should be the correct syntax btw).

Before you say, "use Set Option ". Set option is indeed a possibility, but in the real skin I'm not changing a single shape but many, so in terms of number of characters and code readability is just more optimal to set a single variable than set a whole shape option only to change a single parameter of it, without mentioning I'd need a set option bang per shape.

but to answer, yes, this works:

Code: Select all

IfMatchAction=[!SetOption shapeMeter Shape "rectangle 0,0,[#*Width*],[#*Height*],([#*Width*]*(1/10)) | strokewidth 0"]

But is not what I need.

TIA.

[balala]

So the question is, what is causing this error?

The parenthesis used in the formula used to set the value of the Corners variable into the IfMatchaction option of the [measureMeter] measure. Try removing them: IfMatchAction=[!SetVariable Corners "[#*Width*]*(1/10)"] (or an even simpler form of the same option: IfMatchAction=[!SetVariable Corners "[#*Width*]/10"]).

[RicardoTM]

The parenthesis used in the formula used to set the value of the Corners variable into the IfMatchaction option of the [measureMeter] measure. Try removing them: IfMatchAction=[!SetVariable Corners "[#*Width*]*(1/10)"] (or an even simpler form of the same option: IfMatchAction=[!SetVariable Corners "[#*Width*]/10"]).

Whaaaat, didn't expect that. That's indeed the cause. Any idea why?

[balala]

Any idea why?

When you're enclosing an expression into parenthesis, Rainmeter wants to calculate immediately that expression, the parenthesis expressing it's a mathematical formula (this is why on a String meter for instance, using a FontSize=2*#MyVar# option the size of the font is set to 2, no matter the value of the MyVar variable, while FontSize=(2*#MyVar#) option - using the parenthesis - sets the size of the font to twice the value of the MyVar variable - see the importance of the parenthesis). If you omit the parenthesis, Rainmeter sets for the Corners variable the #Width#*(1/10) value, as a string and the expression is calculated only when the variable is used (in this case on the [shapeMeter] meter).
Obviously this is not too obvious, it can't be, but for people working continuously with Rainmeter codes, this is a known detail.
Glad if you got it working well, using this "trick".

[Yincognito]

I was too tired last night to post the same, but balala is correct... especially when using !SetVariable and escaped variables. For the record, the above will work fine when using a !SetOption instead, see the last paragraph here:
https://docs.rainmeter.net/manual/variables/

This is because, as already described, the value you want to set is a string due to escaping of Width (a string itself), but it's also enclosed between round brackets which alerts Rainmeter that it's a formula where all parts must be resolved to numbers (which is not the case here, obviously). That's why you get the error. By the way, you can workaround this by preceding "([#*Width*]*(1/10))" with a space, like " ([#*Width*]*(1/10))", and not remove any brackets at all, "fooling" Rainmeter into expecting a string and not a formula since an opening round bracket is not the first character in the value you want to set.

One other thing here - although possible, like you already noticed, escaped variables in formulas are not exactly typical in !SetVariable usage, at least not in the codes I wrote. Obviously, this is just personal preference, but I typically use escaping either when defining variables, setting options, or, why not, substitutes. Then, in !SetVariable I just set the variables that are part of such escaped string sequences, letting the escaping / nesting do their job and compute the result according to the individual part I just altered. For example:

Code: Select all

[Variables]
...
widthFactor=(1/20)
Corners=([#*Width*]*[#*widthFactor*])
...

[measureMeter]
measure=String
String=[#Theme]
IfMatch=Theme1
IfMatchAction=[!SetVariable widthFactor (1/10)]
DynamicVariables=1

[RicardoTM]

Thank you guys. Everything makes sense now.

[balala]

Thank you guys. Everything makes sense now.

Glad to help, from my part.

[Yincognito]

Thank you guys. Everything makes sense now.

No problem, I only added some bits to what balala already said.

[RicardoTM]

No problem, I only added some bits to what balala already said.

Yup, I considered adding factors as you suggested since I started it but I didn't want to add much more variables, but now that I've faced the other side of the coin I think I will.

[Yincognito]

Yup, I considered adding factors as you suggested since I started it but I didn't want to add much more variables, but now that I've faced the other side of the coin I think I will.

Well, you already did for the Width and Height formulas, so why not for Corners too?
It might look like overkill at first, but in my experience, the more variables, the more flexible and clean the following code will be. Plus, if you need to change the way things are computed later on, you can do it at the beginning of the code easily. If concerned about the skin code growing larger, you have @includes to place the variables separately anyway. Not saying everything should be "variablized" / "parameterized", but doing it strategically for key things in your code can help.