It is currently March 28th, 2024, 3:39 pm

Variables in the Meter option

Report bugs with the Rainmeter application and suggest features.
Post Reply
User avatar
Yincognito
Rainmeter Sage
Posts: 7024
Joined: February 27th, 2015, 2:38 pm
Location: Terra Yincognita

Variables in the Meter option

Post by Yincognito »

Skin:

Code: Select all

[Variables]
MeterType1=Image
MeterTypeIndex=1

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

---Measures---

[MeterType1]
Measure=String
String=Image
UpdateDivider=-1

---Meters---

[MeterString]
Meter=String
FontFace=Consolas
FontColor=255,255,255,255
SolidColor=47,47,47,255
Padding=5,5,5,5
FontSize=16
AntiAlias=1
Text="A Red Rectangle Should Be Below Me"
UpdateDivider=-1
DynamicVariables=1

[MeterImage]
Meter=Image
;Meter=#MeterType1#
;Meter=[MeterType1]
;Meter=[#MeterType[#MeterTypeIndex]]
Y=0R
W=[MeterString:W]
H=[MeterString:H]
SolidColor=255,0,0,255
UpdateDivider=-1
DynamicVariables=1
The above code works, obviously, but try uncommenting the other 3 Meter=... options one at a time and see what happens. In short, the last 2 commented lines don't work and yield errors. Is this the expected behavior or some sort of mini-bug? I understand that in theory there might be some particularities regarding nested variables, but not sure if they should happen in this case - after all, all the Meter=... lines get the same value, i.e. MeterType1's "Image", in various ways.

Why this matters? Well, I'm just trying to avoid having to use a bunch of @Includes to specify different values of the Meter option (which, as you surely know, can't be included in a MeterStyle, thus volatile variables and @includes were my only variants). The @Include variant works perfectly, by the way, it's just that using variables like above is much clearer and easier to debug, since it's in the same file.

EDIT: I think I understood why the measure line fails, it's probably about reading and parsing the skin before the measure gets the chance to execute, not sure about the nested variable line though (this is my preferred variant for this case, by the way).
User avatar
jsmorley
Developer
Posts: 22628
Joined: April 19th, 2009, 11:02 pm
Location: Fort Hunt, Virginia, USA

Re: Variables in the Meter option

Post by jsmorley »

This is the correct behavior. The "type" of meter OR measure is never allowed to be in any way dynamic or variable. This has to do with the way Rainmeter creates meters and measures when the skin is FIRST read, on load or refresh.

It's why you can't define a meter type in a MeterStyle, and why you can't have for example a Lua script that dynamically creates meters or measures in a loop.

It's nothing to do with "how" you dynamically define the meter or measure type. It doesn't matter what kind of variable you try to use. The type of meter or measure simply must be hard-coded in the actual meter or measure.

It's just in the DNA of how Rainmeter works, and really cannot be changed.
User avatar
Yincognito
Rainmeter Sage
Posts: 7024
Joined: February 27th, 2015, 2:38 pm
Location: Terra Yincognita

Re: Variables in the Meter option

Post by Yincognito »

jsmorley wrote: June 22nd, 2021, 9:45 pm This is the correct behavior. The "type" of meter OR measure is never allowed to be in any way dynamic or variable. This has to do with the way Rainmeter creates meters and measures when the skin is FIRST read, on load or refresh.

It's nothing to do with "how" you dynamically define the meter or measure type. It doesn't matter what kind of variable you try to use. The type of meter or measure simply must be hard-coded in the actual meter or measure.

It's just in the DNA of how Rainmeter works, and really cannot be changed.
I see - thanks for answering, and sorry for bothering you with this. I think I found a working solution, where I write the MeterTypeIndex value in the corresponding .INC and then use the nested syntax in [Variables] in order to produce a plain #MeterType# variable to use in the Meter option. At least this approach works perfectly. :great:
User avatar
jsmorley
Developer
Posts: 22628
Joined: April 19th, 2009, 11:02 pm
Location: Fort Hunt, Virginia, USA

Re: Variables in the Meter option

Post by jsmorley »

Yincognito wrote: June 22nd, 2021, 10:05 pm I see - thanks for answering, and sorry for bothering you with this. I think I found a working solution, where I write the MeterTypeIndex value in the corresponding .INC and then use the nested syntax in [Variables] in order to produce a plain #MeterType# variable to use in the Meter option. At least this approach works perfectly. :great:
I don't follow. NO variable of any kind can be used in the definition of Meter= or Measure=

Code: Select all

[Variables]
MyType=String

[MeterOne]
Meter=#MyType#
FontSize=11
FontWeight=400
FontColor=255,255,255,255
SolidColor=47,47,47,255
Padding=5,5,5,5
AntiAlias=1
Text=Hello World
Fails...
User avatar
jsmorley
Developer
Posts: 22628
Joined: April 19th, 2009, 11:02 pm
Location: Fort Hunt, Virginia, USA

Re: Variables in the Meter option

Post by jsmorley »

Ah, I take that back. The above example does in fact work, if I hadn't fumble-fingered the variable value. So I guess as long as the value for Meter= or Measure= doesn't "change" at any time, it's ok.
User avatar
Yincognito
Rainmeter Sage
Posts: 7024
Joined: February 27th, 2015, 2:38 pm
Location: Terra Yincognita

Re: Variables in the Meter option

Post by Yincognito »

jsmorley wrote: June 22nd, 2021, 10:12 pm Ah, I take that back. The above example does in fact work, if I hadn't fumble-fingered the variable value. So I guess as long as the value for Meter= or Measure= doesn't "change" at any time, it's ok.
Yeah, well, it "changes", just not in the Meter option, but in [Variables], through a bit of indirect !WriteKeyValue-s. :D It's to my advantage, at least I have a solution to work with. I'm doing something like:
Sample.jpg
I'm using it to compare different animation implementations (and their performance) for a rotating Earth I made a while ago. Instead of creating "Variants" of the same skin with only minor differences, I'm just using different small bits of code where needed and select / load the same skin but with the associated parts chosen appropriately.
Post Reply