It is currently March 28th, 2024, 11:00 pm

[Suggestion] Assigning a number to a meter

Report bugs with the Rainmeter application and suggest features.
User avatar
Active Colors
Moderator
Posts: 1251
Joined: February 16th, 2012, 3:32 am
Location: Berlin, Germany

Re: [Suggestion] Assigning a number to a meter

Post by Active Colors »

Active Colors wrote: April 23rd, 2021, 11:07 am Temporary solution

Code: Select all

[Variables]
; Normal behavior
CURRENTSECTIONINDEX=[&CSI:SectionIndex('[#*CURRENTSECTION*]','last','(<x>)')]


;Special for bangs
CSI=
CSIspecial=[&CSIspecial:SectionIndex('[#*CSI*]','last','(<x>)')]



; Normal behavior
[CSI]
Measure=Script
ScriptFile=#@#CSI.lua
UpdateDivider=-1


; Special for bangs (notice you use the same script file)
[CSIspecial]
Measure=Script
ScriptFile=#@#CSI.lua
UpdateDivider=-1



[Meter10]
Meter=Image
MouseOverAction=[!SetVariable CSI #CURRENTSECTION#][!Log #CSIspecial#]
GIF.gif
You can make it pretend to "get" a section name with a fake bang :D

Code: Select all

[Variables]
SectionName=
!GetSectionName=!SetVariable SectionName
CSIspecial=[&CSIspecial:SectionIndex('[#*SectionName*]','last','(<x>)')]


[CSIspecial]
Measure=Script
ScriptFile=#@#CSI.lua
UpdateDivider=-1


[Meter10]
Meter=Image
MouseOverAction=[#!GetSectionName# #CURRENTSECTION#][!Log #CSIspecial#]
User avatar
Yincognito
Rainmeter Sage
Posts: 7029
Joined: February 27th, 2015, 2:38 pm
Location: Terra Yincognita

Re: [Suggestion] Assigning a number to a meter

Post by Yincognito »

Active Colors wrote: April 23rd, 2021, 11:07 amTemporary solution
Yeah, I already tried something similar, but from Lua itself, basically using a temporary variable (and bang) to pass the value of #CURRENTSECTION# to be used later on, though I didn't think of creating another Script measure to help with this. Thing is, I would like to avoid such "hacks", simply because instead of simplifying the solution (which was the whole purpose of my - and probably yours - attempts) it would lead to complicating it. I mean, what good is to have and use #CURRENTSECTION# if you still hav to pass the name of the stupid section manually yourself?! :confused:
Active Colors wrote: April 23rd, 2021, 11:11 am Can you see if you can use GetMeter and GetMeasure for SKIN object, Measure object, and Meter object? All three are described here https://docs.rainmeter.net/manual/lua-scripting/
Yep, checked those too, but there are two issues:
- first, I intentionally avoided using those in my Lua script, to make it applicable to whatever possible scenario (e.g. section doesn't exist, etc.) and have as few "dependencies" as possible (i.e. working just with strings doesn't involve any other "requirements")
- secondly, those two functions still need a NAME for the section to be passed as an argument; on the other hand, this is the whole issue: you can't get the damn name of the current section, when you use the form the code is currently in

The "good" part is that it works without issues (bar those initial errors with 0, that appear to be "normal") if one uses the LITERAL inline Lua syntax and the LITERAL #CURRENTSECTION# in the said bangs.
Profiles: Rainmeter ProfileDeviantArt ProfileSuites: MYiniMeterSkins: Earth
User avatar
Yincognito
Rainmeter Sage
Posts: 7029
Joined: February 27th, 2015, 2:38 pm
Location: Terra Yincognita

Re: [Suggestion] Assigning a number to a meter

Post by Yincognito »

Active Colors wrote: April 23rd, 2021, 11:07 amTemporary solution
Active Colors wrote: April 23rd, 2021, 11:11 amCan you see if you can use GetMeter and GetMeasure for SKIN object, Measure object, and Meter object? All three are described here https://docs.rainmeter.net/manual/lua-scripting/
Active Colors wrote: April 23rd, 2021, 11:34 amYou can make it pretend to "get" a section name with a fake bang :D
Ok, I think I arrived to the simplest solution available: no GetMeter(), no GetMeasure(), no bang (fake or not) ... just splitting the previous #CURRENTSECTIONINDEX# variable into 3 parts:

- the "beginning" of the inline Lua function up until the first parameter's apostrophe (i.e. #GET# below)
- the "middle" which is basically the section name so it can be written literally in order to circumvent the #CURRENTSECTION# problem that Brian mentioned in a related topic (i.e. any section name, without quotes or apostrophes, including #CURRENTSECTION#)
- the "ending" of the inline Lua function from the apostrophe marking the end of the first function parameter to the very end (i.e. #INDEX# below). Of course, the name of these variables can be anything, or be shortened to, say, #G# and #I# or something like that

Script.lua stays the same as before:

Code: Select all

function SectionIndex(section, occurrence, formula)
  local indexes = {}
  for index in section:gmatch('%d+') do table.insert(indexes, index) end
  if occurrence == 'first' then occurrence = 1 elseif occurrence == 'last' then occurrence = #indexes end
  return tostring(SKIN:ParseFormula(string.gsub(formula, '<x>', tostring(indexes[tonumber(occurrence)] or '0')))) or '0'
end
Test.ini suffers slight modifications (I updated the explanation in the comments as well):

Code: Select all

[Variables]
; Inline Lua Usage: [&Script:SectionIndex(SomeSection,SomeOccurrence,SomeFormula)]
; SomeSection     = the name of any section, enclosed by ' (apostrophes), like: 'Measure1' or 'Meter1'
; SomeOccurrence  = the desired occurrence of an index, like: 3 or '5' or 'first' or 'last'
; SomeFormula     = the Rainmeter formula applied to the original <x> index, like: '(<x>)' or '(<x>+1)' or '(Sqrt(<x>))'
; Section variables need to use their nested form, like: [&Script:SectionIndex('[#Section]',[#Occurrence],'[#Formula]')]

; Applicability In:
; - Simulation of getting the current section's "last" index using variables, to avoid repeating inline Lua syntax
;       (Usage: #GET#SomeSection#INDEX#, where SomeSection can be the name of any section, quotes not needed)
; This "hack" of using multiple variables instead of just one hypothetical #CURRENTSECTIONINDEX# was necessary because of
; these #CURRENTSECTION# particularities here: https://forum.rainmeter.net/viewtopic.php?f=14&t=37403&p=190363#p190362
GET=[&Script:SectionIndex('
INDEX=','last','(<x>)')]
; - Alternative equivalent using inline Lua in the skin code: [&Script:SectionIndex('[#CURRENTSECTION]','last','(<x>)')]

[Rainmeter]
Update=1000
DynamicWindowSize=1
AccurateText=1
BackgroundMode=2
SolidColor=47,47,47,255

---Measures---

[Script]
Measure=Script
ScriptFile=#@#Scripts\Script.lua
UpdateDivider=-1
DynamicVariables=1

[MeasureBlah7Blah15Blah3]
Measure=Calc
Formula=(#GET##CURRENTSECTION##INDEX#)
UpdateDivider=-1
IfCondition=(#GET##CURRENTSECTION##INDEX#=3)
IfTrueAction=[!Log "Last index of #CURRENTSECTION# (i.e. #GET##CURRENTSECTION##INDEX#) equals 3"]
IfFalseAction=[!Log "Last index of #CURRENTSECTION# (i.e. #GET##CURRENTSECTION##INDEX#) is not 3"]
IfConditionMode=1
DynamicVariables=1

---Meters---

[MeterResult]
Meter=String
FontFace=Consolas
FontColor=255,255,255,255
SolidColor=47,47,47,255
Padding=5,5,5,5
FontSize=16
AntiAlias=1
MeasureName=MeasureBlah7Blah15Blah3
Text="Result: %1"
DynamicVariables=1
Result is correct, no unwanted side effects noticed yet:
SectionIndexHack.jpg
One advantage of this new "format" is that there is no need for the nested syntax of [#CURRENTSECTION], plain #CURRENTSECTION# works as well. The obvious disadvantage (though minor, in my view, considering the current circumstances of what can and can't be done) is that instead of a single #CURRENTSECTIONINDEX# custom variable, two variables are needed due to breaking the contents of the "old" #CURRENTSECTIONINDEX# into the appropriate "pieces" (i.e. the so called #GET# and #INDEX#, but they could have other names, of course) that are "merged" together to form the whole. Other than that, no other changes are needed (hopefully, LOL).
You do not have the required permissions to view the files attached to this post.
Profiles: Rainmeter ProfileDeviantArt ProfileSuites: MYiniMeterSkins: Earth
User avatar
Jeff
Posts: 326
Joined: September 3rd, 2018, 11:18 am

Re: [Suggestion] Assigning a number to a meter

Post by Jeff »

Yincognito wrote: April 13th, 2021, 7:36 am function GetOption(section, key) return (SKIN:GetMeasure(section) or SKIN:GetMeter(section)):GetOption(key, '0') end
The :GetOption confused me for a while because Rainmeter has the most wonderful implementation of Lua (the above example works but you can't do stuff like Path=SKIN:MakePathAbsolute to clean code up) ever
So much for something that could be solved by MeasureSection :v
Last edited by Jeff on May 7th, 2021, 2:57 pm, edited 1 time in total.
User avatar
Yincognito
Rainmeter Sage
Posts: 7029
Joined: February 27th, 2015, 2:38 pm
Location: Terra Yincognita

Re: [Suggestion] Assigning a number to a meter

Post by Yincognito »

Jeff wrote: May 7th, 2021, 10:54 am The :GetOption confused me for a while because Rainmeter has the most wonderful implementation of Lua (the above example works but you can't do stuff like Path=SKIN:MakePathAbsolute to clean code up) ever
So much for something that could be solved by MeasureSection :v
Sorry, but I don't quite follow what you meant... why would you need Path=SKIN:MakePathAbsolute in this case? Are you trying to get the option from another file than the current skin or what? Also, what is "MeasureSection"?

Anyway, bar the things I couldn't understand, I agree with what you said: the implementation of Lua is great in Rainmeter, and things should be able to be worked out even easier than this. Unfortunately, that's not the case, and the reasons are not the unwillingess, but rather technical ones.
Profiles: Rainmeter ProfileDeviantArt ProfileSuites: MYiniMeterSkins: Earth
User avatar
Jeff
Posts: 326
Joined: September 3rd, 2018, 11:18 am

Re: [Suggestion] Assigning a number to a meter

Post by Jeff »

That was sarcasm, the 3 points I was trying to make are:

1. The name of the function and the SKIN object manipulator (with the colon) are exactly the same, normally when a colon method like that is called you would expect the syntax to apply the method (like a:x which is also equivalent to a.x or a["x"] or whatever other form it takes), in Rainmeter it's the opposite where you can have both in there and you can't do SKIN.Bang either
2. In Lua you can make other strings refer to functions, e.g. s,c,r = math.sin, math.cos, math.random and just call it like s(55), in Rainmeter's Lua you can't really do that, var = SKIN:GetVariable and then trying var('Color1') just errors, I think this only happens with the SKIN object, still annoying
3. The (you also have a good advantage with this cause you can use #CurrentSection#) in my first reply was a really subtle note to the fact that this is really the only way to do MeasureStyle
Right now for MeterStyle you can just do

Code: Select all

[Variables]
Icon0="#@#Move.png"
Icon1="#@#Calculator.png"
;...
Action0=[]
Action1=["Calc.exe"]
;...
ToolTipText0="Move"
ToolTipText1="Calculator"
;...
[Style]
ImageName=[#Icon[#CURRENTSECTION]]
LeftMouseUpAction=[#Action[#CURRENTSECTION]]
ToolTipText=[#ToolTipText[#CURRENTSECTION]]
W=60
H=60
X=20R
Y=r

[0]
Meter=Image
MeterStyle=Style
X=10r
Y=10
[1]
Meter=Image
MeterStyle=Style
[2]
Meter=Image
MeterStyle=Style
and you're fine, If you wanna do the same thing with MeasureStyle, you'll sadly have to do something like

Code: Select all

[0]
Measure=Calc
MinValue=[&Script:PullOption('Measure', 'Meter[#CurrentSection]', 'X')]
MaxValue=[&Script:PullOption('Measure', 'Meter[#CurrentSection]', 'W')]
DynamicVariables=1
[1]
Measure=Calc
MinValue=[&Script:PullOption('Measure', 'Meter[#CurrentSection]', 'X')]
MaxValue=[&Script:PullOption('Measure', 'Meter[#CurrentSection]', 'W')]
DynamicVariables=1
[2]
Measure=Calc
MinValue=[&Script:PullOption('Measure', 'Meter[#CurrentSection]', 'X')]
MaxValue=[&Script:PullOption('Measure', 'Meter[#CurrentSectio]#', 'W')]
DynamicVariables=1
, this is the only method I can imagine of creating a MeasureStyle right now, which I also thought what was OP wanted as well but oh well
User avatar
Yincognito
Rainmeter Sage
Posts: 7029
Joined: February 27th, 2015, 2:38 pm
Location: Terra Yincognita

Re: [Suggestion] Assigning a number to a meter

Post by Yincognito »

Jeff wrote: May 9th, 2021, 6:38 pmThat was sarcasm, the 3 points I was trying to make are: [...]
1. Yeah, the exact name was intentional, but although it might be confusing, I thought the context in which they are both used wouldn't cause conflicts and would liken the Rainmeter syntax with that of Lua a bit. Obviously, there are differences between them and that shouldn't be forgotten - if the similarity is a problem, the name of the function can quite easily be changed.

2. I'm not sure if you're talking about splitting a '255,128,0,255' color string and extracting the Color1, i.e. the RED from it (which can be done using some gsub() kung fu and such), or "compiling" the s (string, since not possible otherwise) variable, i.e. 'math.sin' and getting the result of math.sin(55), where 55 would be the value of Color1. If it's the latter, it can surely be done, though in a bit convoluted way (before you say it's not the same as the simpler s(55), bear in mind that it would have been precisely the same if your s variable was declared as a string, even in Lua itself - and since Rainmeter knows only string and numbers and not "functions", you get the idea)...

Script:

Code: Select all

function Update()
  loadstring('result = '..SKIN:GetVariable('s')..'('..SKIN:GetVariable('Color1')..')')()
  return result
end
Skin:

Code: Select all

[Variables]
Color1=55
s=math.sin
c=math.cos
r=math.random

[Rainmeter]
Update=1000
DynamicWindowSize=1
AccurateText=1
BackgroundMode=2
SolidColor=47,47,47,255

---Measures---

[Script]
Measure=Script
ScriptFile=#@#test.lua
UpdateDivider=-1
DynamicVariables=1

---Meters---

[MeterTest]
Meter=String
X=0
Y=0
FontFace=Consolas
FontColor=255,255,255,255
SolidColor=47,47,47,255
Padding=5,5,5,5
FontSize=16
AntiAlias=1
MeasureName=Script
Text="Test = %1"
NumOfDecimals=2
DynamicVariables=1
Reference
Programming in Lua - Compilation, Execution, and Errors

This will correctly yield math.sin(55), aka -1, and will have no problems with the c and r variables either. Had to add 2 decimals at the end since I didn't want to use a Calc measure just to avoid rounding the result to 0 decimals in Rainmeter's String meters. I hate error handling so I skipped the "proper" way of doing it, i.e. assert(loadstring(...)). If I remember correctly from when I worked with that, Javascript has a similar function that compiles a text into "code", so I was surprised to see Lua similar in that regard, when I looked for options to use in my own code a couple of weeks ago (in the end, I didn't need to use it anymore, but since you mentioned this, there you go).

If it's just about sin, cos and random numbers, you can probably use SKIN:ParseFormula() as well with Rainmeter's built in functions. In case you meant that "you can't do it as simple as s(55)" ... well, that's it, you have to work with what you got, but it is possible.

3. I know what you mean. It's probably the only way, though I didn't try simulating a "measure style" using @Includes... if that's even possible in the first place (and even if it is, using all sorts of nested and somewhat "circular references" there would not end well, I reckon). To be clear, one can use #CURRENTSECTION# in my variants as well, just not directly shortening up the code to create a custom variable to avoid inline Lua, that's all (indirectly it's still possible by breaking the custom variable so that #CURRENTSECTION# is written literally when needed). Correction: I realized you were referring to the commented code at the end of my first posted reply here (any idea why that happens? I mean, it otherwise works as expected). And yes, I've expanded the original OP question / request, simply because the issues are so closely related. Not much difference between extracting an "option" from a section and extracting an "index" out of it... :confused:

EDIT: I tested your original code just now (sorry, but I trusted you without testing your code first in the beginning), and:
- you have 2 syntax mistakes in the conditions: it should be if section == 'Meter' and elseif section == 'Measure' instead of using a single equality sign like in variable assignments
- your code breaks the font size (possibly the FontFace as well, though not sure), just like mine

I used:

Code: Select all

function PullOption(section, name, key)
	if section == 'Meter' then m = SKIN:GetMeter(name)
	elseif section == 'Measure' then m = SKIN:GetMeasure(name)
	else print("We're both stupid or you did something wrong")
	end
	return m:GetOption(key, '0')
end
and

Code: Select all

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

---Measures---

[Script]
Measure=Script
ScriptFile=#@#Script.lua
UpdateDivider=-1

---Styles---

[TextStyle]
Y=0R
FontFace=Consolas
FontColor=255,255,255,255
SolidColor=47,47,47,255
Padding=5,5,5,5
FontSize=26
AntiAlias=1

---Meters---

[Meter1]
Meter=String
MeterStyle=TextStyle
Group=10
Text="Meter [&Script:PullOption('Meter', 'Meter1', 'Group')]"
DynamicVariables=1
handling stuff using Groups, as advised. Note that the font size is set to 26, but it's much smaller in practice. As you can see, it has nothing to do with #CURRENTSECTION#. I'm guessing it's almost (?) the same problem with operations happening in the wrong "expected" order due to Rainmeter's initial parsing of the skin (which replaces section variables and possibly breaks the font). Ideas?
Profiles: Rainmeter ProfileDeviantArt ProfileSuites: MYiniMeterSkins: Earth
User avatar
Active Colors
Moderator
Posts: 1251
Joined: February 16th, 2012, 3:32 am
Location: Berlin, Germany

Re: [Suggestion] Assigning a number to a meter

Post by Active Colors »

There is a problem with having formulas in variables which use [#*GET*][#*CURRENTSECTION*][#*INDEX*] statement.
When there is more than one value in the formula it will fail to calculate beyond the first value.

For instance, this will work:

Code: Select all

[Variables]
CalcThis=([MeterExample[#*GET*][#*CURRENTSECTION*][#*INDEX*]:W])

[MeterExample1]
Meter=String
X=5
Y=30
FontFace=Consolas
FontColor=255,255,255,255
FontSize=12
AntiAlias=1
Text=Example text

[MeasureCalc1]
Measure=Calc
Formula=[#CalcThis]
DynamicVariables=1

While this will not:

Code: Select all

[Variables]
CalcThis=([MeterExample[#*GET*][#*CURRENTSECTION*][#*INDEX*]:W]+[MeterSample[#*GET*][#*CURRENTSECTION*][#*INDEX*]:W])

[MeterExample1]
Meter=String
X=5
Y=30
FontFace=Consolas
FontColor=255,255,255
FontSize=12
AntiAlias=1
Text=Example text

[MeterSample1]
Meter=String
X=5
Y=30
FontFace=Consolas
FontColor=255,255,255
FontSize=12
AntiAlias=1
Text=Sample

[MeasureCalc1]
Measure=Calc
Formula=[#CalcThis]
DynamicVariables=1

I noticed it while testing something. This is not something that requires immediate tackling. Maybe you can spot the problem?
User avatar
Yincognito
Rainmeter Sage
Posts: 7029
Joined: February 27th, 2015, 2:38 pm
Location: Terra Yincognita

Re: [Suggestion] Assigning a number to a meter

Post by Yincognito »

Active Colors wrote: June 26th, 2021, 9:40 pmThere is a problem with having formulas in variables which use [#*GET*][#*CURRENTSECTION*][#*INDEX*] statement.
I noticed it while testing something. This is not something that requires immediate tackling. Maybe you can spot the problem?
Yes, I identified the problem, and although in theory this shouldn't happen, it's the way Rainmeter works (remember the issues with formulas from earlier? I believe they are all connected). Make a string measure like this:

Code: Select all

[MeasureString1]
Measure=String
String=[#CalcThis]
DynamicVariables=1
and place it before the Calc measure, and you'll see the result: the 2nd "getcurrentsectionindex" is 0. This happens even if you swap the formula's elements between them, and will happen, hilariously, even if you repeat a previously well detected "getcurrentsectionindex" as the 3rd element in the addition. Try these, one at a time:

Code: Select all

CalcThis=([MeterExample[#*GET*][#*CURRENTSECTION*][#*INDEX*]:W])
CalcThis=([MeterSample[#*GET*][#*CURRENTSECTION*][#*INDEX*]:W])
CalcThis=([MeterExample[#*GET*][#*CURRENTSECTION*][#*INDEX*]:W]+[MeterSample[#*GET*][#*CURRENTSECTION*][#*INDEX*]:W])
CalcThis=([MeterSample[#*GET*][#*CURRENTSECTION*][#*INDEX*]:W]+[MeterExample[#*GET*][#*CURRENTSECTION*][#*INDEX*]:W])
CalcThis=([MeterExample[#*GET*][#*CURRENTSECTION*][#*INDEX*]:W]+[MeterSample[#*GET*][#*CURRENTSECTION*][#*INDEX*]:W]+[MeterExample[#*GET*][#*CURRENTSECTION*][#*INDEX*]:W])
The last 3 forms won't work.

That being said, they don't work not necessarily because they're formulas, but because the whole key in my "custom variable break-up" approach / workaround, i.e. #GET##CURRENTSECTION##INDEX#, is to have #CURRENTSECTION# written LITERALLY when used (so it can be "catched" by Rainmeter and properly replaced). What you did is escape each of the 3 break-up parts, meaning Rainmeter does some extra-parsing / extra-replacing / whatever and doesn't get the chance to "find out" and "prepare itself" for replacing 2 or more #CURRENTSECTION#-s and instead only replaces the 1st one (don't ask me why, ask Brian, LOL).

Some relatively interesting, and I believe also connected from a Rainmeter behavior point of view, you can find in my bug report and Brian answer here. I guess here it's partly about #CURRENTSECTION#, partly about formulas, partly about nested variables and partly about escaping "tricky" variables like #CURRENTSECTION#. The linked post explains a bit the nested variables and, if you use your imagination to equate #CURRENTSECTION# and the !Delay bang and their "preferential" (read: tricky) treatment, it becomes clearer why such isues happen.

But enough with the pointless explanation of something that (again) shouldn't happen - the solution is to make use of the key in my "custom variable break-up" approach mentioned earlier, i.e. using literal [#CURRENTSECTION] where you need:

Code: Select all

Formula=([MeterExample[#GET][#CURRENTSECTION][#INDEX]:W]+[MeterSample[#GET][#CURRENTSECTION][#INDEX]:W])
This should work irrespective of the formula written there, simply because those pesky [#CURRENTSECTION] are plainly visible to Rainmeter and it can parse / pre-parse / whatever stuff to get to the correct result. I know, these "tricks" are a pain in the a** to use, but at least there is a solution available. Obviously, using the inline syntax will always work as well:

Code: Select all

Formula=([MeterExample[&Script:SectionIndex('[#CURRENTSECTION]','last','(<x>)')]:W]+[MeterSample[&Script:SectionIndex('[#CURRENTSECTION]','last','(<x>)')]:W])
for the same reason, i.e. all the [#CURRENTSECTION] occurences being visible to the Rainmeter parser. Rainmeter needs to be able to replace these instances with the actual section names before sending those section names to Lua as plain strings, since #CURRENTSECTION#, as previously alluded by Brian, has no meaning and can't be retrieved by Lua itself, even if you're using SKIN:ReplaceVariables().
Profiles: Rainmeter ProfileDeviantArt ProfileSuites: MYiniMeterSkins: Earth
User avatar
death.crafter
Rainmeter Sage
Posts: 1399
Joined: April 24th, 2021, 8:13 pm

Re: [Suggestion] Assigning a number to a meter

Post by death.crafter »

Active Colors wrote: June 26th, 2021, 9:40 pm There is a problem with having formulas in variables which use [#*GET*][#*CURRENTSECTION*][#*INDEX*] statement.

I noticed it while testing something. This is not something that requires immediate tackling. Maybe you can spot the problem?
I may be thrown off a bit here. Is [#*GET*][#*CURRENTSECTION*][#*INDEX*] a way to get the index of a section? I'm pretty sure it is not. Anyway, this piece works fine for me:

Code: Select all

[Variables]
INDEX=2
GET=2
CalcThis=([MeterExample[#*GET*][#*CURRENTSECTION*][#*INDEX*]:W]+[MeterSample[#*GET*][#*CURRENTSECTION*][#*INDEX*]:W])

[MeterExample212]
Meter=String
X=5
Y=30
FontFace=Consolas
FontColor=255,255,255,255
FontSize=12
AntiAlias=1
Text=Example text

[MeterSample212]
Meter=String
X=5
Y=30
FontFace=Consolas
FontColor=255,255,255
FontSize=12
AntiAlias=1
Text=Example text

[1]
Measure=Calc
Formula=[#CalcThis]
DynamicVariables=1
Did I go wrong somewhere?
from the Realm of Death