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...
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?
