It is currently July 19th, 2019, 12:39 am

An issue concerning variables.

Report bugs with the Rainmeter application and suggest features.
User avatar
JelleDekkers
Posts: 19
Joined: September 27th, 2017, 6:32 pm

An issue concerning variables.

JelleDekkers » April 20th, 2019, 3:32 pm

Let's say we have three variables. Width1, Width2 and Width3. Width3 is the sum of Width1 and Width2.

Code: Select all

[Variables]
Width1=10
Width2=20
Width3=(#Width1#+#Width2#)
Now if you look in the log window, the string value of Width3 is "(10+20)", which is exactly what we want because it can be used in formulas.

If we were to put the Width3 variable above the Width1 and Width2 variables in the code, the log window displays "(#Width1#+#Width2#)" as the value of the Width3 variable. This gives you a syntax error when used in a formula, because you can't use text in a formula.

Here's an example of a real skin with this issue:

As you can see, changing the order of the SkinWidth and SkinHeight variables breaks parts of the skin. If the order of the variables didn't matter, like a few devs told me it doesn't, this would certainly not be the case.
User avatar
jsmorley
Developer
Posts: 19293
Joined: April 19th, 2009, 11:02 pm
Location: Fort Hunt, Virginia, USA

Re: An issue concerning variables.

jsmorley » April 20th, 2019, 4:00 pm

Huh. I would not have expected that, but you are right. The order does matter in this instance.

Code: Select all

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

[Variables]
Width3=(#Width1#+#Width2#)
Width1=10
Width2=20
;Width3=(#Width1#+#Width2#)

[MeasureCalc]
Measure=Calc
Formula=#Width3#
DynamicVariables=1

[MeterResult]
Meter=String
MeasureName=MeasureCalc
FontSize=11
FontWeight=400
FontColor=255,255,255,255
SolidColor=47,47,47,255
Padding=5,5,5,5
AntiAlias=1
This does produce a syntax error in the [MeasureCalc] measure, and it's value is set to 0. If I move the definition of Width3 down below the other definitions, then it works as expected. This is in a sense "logical" that it fails, but I'm a bit surprised that it does.

So I guess the answer is to try and stay away from defining variables where an earlier variable is dependent on the value of a later variable.
User avatar
JelleDekkers
Posts: 19
Joined: September 27th, 2017, 6:32 pm

Re: An issue concerning variables.

JelleDekkers » April 20th, 2019, 4:15 pm

So nothing's going to be done to fix this?
User avatar
jsmorley
Developer
Posts: 19293
Joined: April 19th, 2009, 11:02 pm
Location: Fort Hunt, Virginia, USA

Re: An issue concerning variables.

jsmorley » April 20th, 2019, 4:25 pm

Fix what? Why WOULD you expect to be able to use a variable before it is defined?
User avatar
JelleDekkers
Posts: 19
Joined: September 27th, 2017, 6:32 pm

Re: An issue concerning variables.

JelleDekkers » April 20th, 2019, 4:47 pm

I thought variables weren't being resolved inside of [Variables]? If they weren't, I wouldn't be "using" the variables before they are defined.

Also, if the order does matter, I suggest the variables in the log window are ordered the way they are read. And make them case-sensitive, just like the measures. You're not going to tell me measures are case senstitive, are you?
User avatar
jsmorley
Developer
Posts: 19293
Joined: April 19th, 2009, 11:02 pm
Location: Fort Hunt, Virginia, USA

Re: An issue concerning variables.

jsmorley » April 20th, 2019, 4:57 pm

JelleDekkers wrote:
April 20th, 2019, 4:47 pm
I thought variables weren't being resolved inside of [Variables]? If they weren't, I wouldn't be "using" the variables before they are defined.

Also, if the order does matter, I suggest the variables in the log window are ordered the way they are read. And make them case-sensitive, just like the measures. You're not going to tell me measures are case senstitive, are you?
I was wrong when I told you in IRC that the order of things in [Variables] doesn't matter. Clearly it does. That's not a bug, it's perfectly logical, just a bit of a surprise to me. Oh well, you live and learn.

I doubt that we are going to change how variables are displayed in About / Skins. They are lower case as when they are read by Rainmeter, they are pretty much instantly converted to lower case, and that is how they are carted around in memory. This is to eliminate issues with the fact that while Rainmeter is case-insensitive, C++ most assuredly isn't. Also, since Variables can be defined, or re-defined, at any time anywhere in the skin using Bangs, this would make it difficult indeed to order them in any logical way other than alphabetical.

Measures are a bit different, since they can only be defined once, when the skin is read on load or refresh, in the order they are in the skin.

Brian may want to weigh in, but I don't see this as an issue we would want to spend a lot of time on.
User avatar
jsmorley
Developer
Posts: 19293
Joined: April 19th, 2009, 11:02 pm
Location: Fort Hunt, Virginia, USA

Re: An issue concerning variables.

jsmorley » April 20th, 2019, 5:11 pm

Make no mistake, in a perfect world Variables would be displayed in the order in which they are initially created, whether in [Variables] or via a bang, and would be in the same case as they are initially created. Neither of these are particularly important, but since you go to some lengths to name things in a way that makes the code easier to read, and this includes what case is used, we should really preserve that in the log.

One could argue that if you have a LOT of variables, checking the value of one of them might be easier in alphabetical order, but that isn't an argument I would make.
User avatar
JelleDekkers
Posts: 19
Joined: September 27th, 2017, 6:32 pm

Re: An issue concerning variables.

JelleDekkers » April 20th, 2019, 5:21 pm

I think it's more logical to order them in the way they are read, because apparently that does matter. For the variables created with a bang after the skin is read, I would place them at the end of the pre-defined variables. I would also place variables that have been changed with a bang at the bottom. I assume the last variable made is also the last one read.

PS: I always name things like this, so it's a lot easier for me to go back and make some changes. One could also argue that it makes it easier for other people to change stuff, because the section and variable names are self-explanatory.