It is currently July 16th, 2024, 1:42 pm

Formulas within nested inline Lua causing unexpected behavior

Discuss the use of Lua in Script measures.
Crest
Posts: 148
Joined: August 16th, 2013, 12:47 pm

Formulas within nested inline Lua causing unexpected behavior

Post by 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
Last edited by Crest on June 3rd, 2024, 10:24 am, edited 1 time in total.
Crest
Posts: 148
Joined: August 16th, 2013, 12:47 pm

Re: Formulas within nested inline Lua causing unexpected behavior

Post by 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.
User avatar
Yincognito
Rainmeter Sage
Posts: 7731
Joined: February 27th, 2015, 2:38 pm
Location: Terra Yincognita

Re: Formulas within nested inline Lua causing unexpected behavior

Post by 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.
Profiles: Rainmeter ProfileDeviantArt ProfileSuites: MYiniMeterSkins: Earth
Crest
Posts: 148
Joined: August 16th, 2013, 12:47 pm

Re: Formulas within nested inline Lua causing unexpected behavior

Post by Crest »

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.
User avatar
Yincognito
Rainmeter Sage
Posts: 7731
Joined: February 27th, 2015, 2:38 pm
Location: Terra Yincognita

Re: Formulas within nested inline Lua causing unexpected behavior

Post by Yincognito »

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. :???:
Profiles: Rainmeter ProfileDeviantArt ProfileSuites: MYiniMeterSkins: Earth