This is a separate issue from the since confirmed bug in the other thread (though it uses some similar functions). What is occurring is one inline Lua function is obtaining an inline function from a custom option stored in a meter but is getting mangled when it contains certain formulas due to some unexpected parsing.
It appears to be related to parentheses and possibly quotes but I've tried with multiple different quoting methods and can't seem to avoid the behavior.
The `Chk()` function (correctly) parses and returns the `Cust` option stored in its own meter (uncomment the `print()` line from the script to view the returned string). This option itself contains an inline function. For the `ExampleText` meter this just returns a concatenation of the two input arguments which are then displayed as a string.
However despite displaying the strings as expected in the string meter if one uncomments the `print()` line in the `Disp()` function and looks at the Rainmeter log it's showing that on subsequent skin updates the second argument gets mangled and becomes a nil value.
This is made more obvious in the second `Example` meter. The first commented out `Cust` option function of that meter works as expected, both strings are equivalent so it returns the third arg (there are also no formulas in this version). However the uncommented `Cust` function fails due to unexpected parsing (see log), so no shape height is produced due to the errors.
Test case with various examples to play around with (see Rainmeter log and comments):
[Variables]
S=20
H=50
W=200
[Rainmeter]
AccurateText=1
DynamicWindowSize=1
Update=3000
[Sc]
Measure=Script
ScriptFile=Script.lua
[ExampleText]
Meter=String
W=#W#
H=#H#
Cust=[&Sc:Disp('([#CURRENTSECTION#:W] / 2)','([#CURRENTSECTION#:W] * 2)')]
Text=[&Sc:Chk('#CURRENTSECTION#','Cust')] [ExampleText:W]
FontColor=230,230,230
SolidColor=0,0,0
DynamicVariables=1
[Example]
Meter=Shape
X=0r
Y=0R
Shape=Rectangle 0,0,#W#,[&Sc:Chk('#CURRENTSECTION#','Cust')],0 | Fill Color 244,119,111 | StrokeWidth 0
; Working as expected:
; Cust=[&Sc:Repl('true','true','10','100')]
; Here the equivalence comparison of first two args should produce a return value of '10' but it parses incorrectly altogether (see log):
Cust=[&Sc:Repl('([#CURRENTSECTION#:W] / 2)','([#CURRENTSECTION#:W] / 2)','10','100')]
; Another example of unexpected behavior:
; Cust=[&Sc:Repl('([#CURRENTSECTION#:W] / 2)','(#W# / 2)','(Round([#CURRENTSECTION#:H] / 2))','[#CURRENTSECTION#:H]')]
DynamicVariables=1
function Initialize()
end
function Disp(in1,in2)
-- print("Disp(): ",in1,in2)
return in1.." "..in2
end
function Repl(in1,in2,ret,el)
print("Repl(): ",in1,in2,ret,el)
if in1 == in2 then
return ret
else
if el then
return el
else
return ""
end
end
end
function Chk(name,op)
local m = SKIN:GetMeter(name)
local o = m:GetOption(op,'',false)
if o then
-- Notice the return value is as expected:
-- print(o)
return o
else
return 0
end
end
Last edited by Crest on June 3rd, 2024, 10:24 am, edited 1 time in total.
Should also mention that for the most of the above examples which only (ultimately) involve number based comparisons they could be alternatively replaced by the native formula conditional syntax but since I use the function for also string comparisons I'd come across the issue so wondered what is causing it.
Not sure exactly what you expect the result to be, but I think that using the SKIN object's functions like GetVariable() / ReplaceVariables() / ParseForumula() as necessary in the Lua script should return what you need: https://docs.rainmeter.net/manual/lua-scripting/
Additionally, you'd better check the Nested Variables in Rainmeter section on this page: https://docs.rainmeter.net/manual/lua-scripting/inline-lua/
and use something like [&#CURRENTSECTION#:W] instead of simply [#CURRENTSECTION#:W], for example. I know these are meters and not measures and the & is not absolutely needed, but then it doesn't hurt to use it for meters either, if anything, for the principle itself.
Yincognito wrote: ↑June 3rd, 2024, 9:59 am
Additionally, you'd better check the Nested Variables in Rainmeter section on this page: https://docs.rainmeter.net/manual/lua-scripting/inline-lua/
and use something like [&#CURRENTSECTION#:W] instead of simply [#CURRENTSECTION#:W], for example. I know these are meters and not measures and the & is not absolutely needed, but then it doesn't hurt to use it for meters either, if anything, for the principle itself.
This was the solution. Thanks.
I'd actually already checked that page (and searched the forum) but it didn't mention your suggested syntax, instead it lists `[#VarName]` to be used instead of `#VarName#` which I'd tried without it making any difference (and various combinations per the other Nested Variables docs page). While the `[&...` is listed exclusively for measures so wasn't obvious.
Perhaps the `#CURRENTSECTION#` variable is unique in that regard (in that it requires a unique hybrid syntax)? Would be worthwhile added to the docs as some extra example perhaps.
Crest wrote: ↑June 3rd, 2024, 10:23 am
This was the solution. Thanks.
I'd actually already checked that page (and searched the forum) but it didn't mention your suggested syntax, instead it lists `[#VarName]` to be used instead of `#VarName#` which I'd tried without it making any difference (and various combinations per the other Nested Variables docs page). While the `[&...` is listed exclusively for measures so wasn't obvious.
Perhaps the `#CURRENTSECTION#` variable is unique in that regard (in that it requires a unique hybrid syntax)? Would be worthwhile added to the docs as some extra example perhaps.
You're welcome, glad it worked for you. Yeah, #CURRENTSECTION# is indeed a unique variable (at one point, its value couldn't be retrieved from Lua, if I remember correctly), but it's not related to the case above - the idea is the same for all variables or section variables like measures or meters when used in the inline Lua syntax. On a second thought, now that you mentioned it, I think you could even use the nested syntax for all parts, like [&[#CURRENTSECTION]:W], and achieve the same thing, if you wanted to be pedantic about it.