Inline Lua and formula arguments

[Yincognito]

Here I come with another Lua issue, or, if not an issue, at least some difference between what the manual says and what actually happens...

1) The manual (I included a typo, just to spice things up...):

The syntax of an inline Lua call to a function() is:

[&ScriptMeasureName:LuaFunctionName(numberParameter, 'stringParameter', ...)]

Examples:
[&MeasureMyScript:GetCharaceterInString('Rainmeter', 5)]
[&MeasureMyScript:ConvertTemperature([&MeasureCurrentTemp], 'C')]

The types of parameters that can be passed to the Lua function() are:

Number Any number literal, formula or variable that resolves to a number.
String Any 'string' literal, or variable that resolves to a string, enclosed in 'single quotes'.
Boolean One of either true or false.

2) What actually happens...

#@#Script.lua:

Code: Select all

function Result(number)
  return number
end

Test.ini:

Code: Select all

[Variables]

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

---Measures---

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

---Meters---

[MeterTest]
Meter=String
FontFace=Consolas
FontColor=255,255,255,255
Padding=5,5,5,5
FontSize=16
AntiAlias=1
Text="Script = [&MeasureScript:Result((7+3))]"
UpdateDivider=-1
DynamicVariables=1

So, according to the manual (or at least my understanding of it), the Result() function's argument / parameter should be (7+3) ... which is a "formula that resolves to a number", i.e. 10. Thus, Lua should receive the call to Result(10) and return 10, but it doesn't and returns 0, meaning the parsing "failed" or rather it expected a number literal or a variable only. As a side not, if I do [&MeasureScript:Result(7+3)], i.e. using only one set of round brackets, I get 7.

I know I can call SKIN:ParseFormula() from within Lua if I pass the operation as a string and all that, but I thought the formula would be parsed by Rainmeter before sending it to Lua, similar to how Rainmeter variables are parsed before they get to Lua. Was I mistaken?

P.S. Feel free to move this thread appropriately if this is a bug.

[Brian]

Hmmm. I am not sure this is quite a bug since lua custom function parameters have never been ran through the Rainmeter math parser before going to the lua script. They weren't designed to either...so I am not sure why the docs say they do. It was probably just an oversight when creating the inline function docs.

However, maybe they should be....at least parameters that are deemed to NOT be strings nor booleans.

I'll have to chew on this a bit to see if it's necessary, since you can do it with the SKIN:ParseFormula function as you stated (as long as the parameter is sent as a string).

-Brian

PS - The "String" part stating that only single quotes should be used is somewhat misleading. It will accept double quotes as well.

[Yincognito]

Hmmm. I am not sure this is quite a bug since lua custom function parameters have never been ran through the Rainmeter math parser before going to the lua script. They weren't designed to either...so I am not sure why the docs say they do. It was probably just an oversight when creating the inline function docs.

However, maybe they should be....at least parameters that are deemed to NOT be strings nor booleans.

I'll have to chew on this a bit to see if it's necessary, since you can do it with the SKIN:ParseFormula function as you stated (as long as the parameter is sent as a string).

-Brian

PS - The "String" part stating that only single quotes should be used is somewhat misleading. It will accept double quotes as well.

Alrighty then - will let you weigh on this properly. So far I took the string route in my case, but obviously it would be easier and more logical for this to work right from Rainmeter. If this doesn't complicate the parsing being done too much, that is. In any case, it's a contradiction between what the manual says and what happens here, that thing is clear. Feel free to choose whatever you deem to be best, logical and feasible.

P.S. The reason I mentioned this in the first place is because, if you don't go the string / ParseFormula() route, the only choice is to create other (Calc) measures in Rainmeter to compute things beforehand. In some cases (like dynamically using different sums, like (7+1) in the first meter, (7+2) in the second meter, (7+3) in the third meter and so on) this is quite difficult to do using Calc measures...

[Yincognito]

One other thing somewhat related that I face now in this case is passing a Lua / C++ string format like say '%2d' to pad a value with spaces. When doing that, Rainmeter replaces %2 with the 2nd MeasureName, if it happens to have one. Basically, this is a reverse example compared to before, i.e. when Rainmeter actually correctly parses something before sending it to Lua, it just that incidentally this would be a case where you wouldn't want that parsing in order to send the literal string to Lua. Of course, I assumed that the '%2d' string is not truncated to eliminate the '%'.

[Brian]

Alrighty then - will let you weigh on this properly. So far I took the string route in my case, but obviously it would be easier and more logical for this to work right from Rainmeter. If this doesn't complicate the parsing being done too much, that is. In any case, it's a contradiction between what the manual says and what happens here, that thing is clear. Feel free to choose whatever you deem to be best, logical and feasible.

P.S. The reason I mentioned this in the first place is because, if you don't go the string / ParseFormula() route, the only choice is to create other (Calc) measures in Rainmeter to compute things beforehand. In some cases (like dynamically using different sums, like (7+1) in the first meter, (7+2) in the second meter, (7+3) in the third meter and so on) this is quite difficult to do using Calc measures...

This has been added for the next release. Only numeric parameters should be affected, and you have "start" your parameter will a ( like in other parts of Rainmeter.

Good:
[Script:Function((7+2))

Bad:
[Script:Function(5+(7+2))

---

I also added the ability to specify "nil" as a parameter as well. Usage: nil - no parenthesis or quotes. Just the actual word, similar to true and false. These 3 parameters are no longer case sensitive (on the Rainmeter side, not lua side).

-Brian

[Brian]

One other thing somewhat related that I face now in this case is passing a Lua / C++ string format like say '%2d' to pad a value with spaces. When doing that, Rainmeter replaces %2 with the 2nd MeasureName, if it happens to have one. Basically, this is a reverse example compared to before, i.e. when Rainmeter actually correctly parses something before sending it to Lua, it just that incidentally this would be a case where you wouldn't want that parsing in order to send the literal string to Lua. Of course, I assumed that the '%2d' string is not truncated to eliminate the '%'.

Yeah, this "percent replacement" method is only used on the String meter's Text option, and also on ToolTipText options. I do not believe they are used anywhere else in Rainmeter.

I'd have to think about some form of "escaping" for this, but I am not sure of the "need" for it as a whole. Maybe just send the "number" instead of both the percent and number...if you get what I mean, at least for the time being.

-Brian

[Yincognito]

This has been added for the next release. Only numeric parameters should be affected, and you have "start" your parameter will a ( like in other parts of Rainmeter.

Good:
[Script:Function((7+2))

Bad:
[Script:Function(5+(7+2))

---

I also added the ability to specify "nil" as a parameter as well. Usage: nil - no parenthesis or quotes. Just the actual word, similar to true and false. These 3 parameters are no longer case sensitive (on the Rainmeter side, not lua side).

-Brian

Excellent news, thanks!

Yeah, this "percent replacement" method is only used on the String meter's Text option, and also on ToolTipText options. I do not believe they are used anywhere else in Rainmeter.

I'd have to think about some form of "escaping" for this, but I am not sure of the "need" for it as a whole. Maybe just send the "number" instead of both the percent and number...if you get what I mean, at least for the time being.

-Brian

Yeah. I already have been sending only the truncated part to Lua, e.g. [&Script:SomeFunction('SomeFormulaOrString','s')] or [&Script:SomeFunction('SomeFormulaOrString','02d')], adding there the '%' prefix and using it to decide whether to return the ParseFormula(value) or the raw value based on the formatting string (i.e. raw value if 's', parse formula if otherwise), I only mentioned this in order for you to be aware of such a possibility / conflict. Eventually, I ended up manipulating things in native Rainmeter so the zero padding is not necessary anymore from within Lua. The approach will remain there as it's useful though, and of course adding the above parsing is perfect for numbers and formula only situations, which I also have in the code.