Formulas within nested inline Lua causing unexpected behavior

[Crest]

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):

INI:

Code: Select all

[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

Script:

Code: Select all

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

[Crest]

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.

[Yincognito]

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.

[Crest]

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.

[Yincognito]

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.