Then the result is only asked for and set on each UpdateRate of the parent WebParser measure, and no DynamicVariables is needed on the String meter. Same result, slightly more efficient.
jsmorley wrote:Not really a disadvantage as such, but just not the logical way to do it in my view. You want the result "on demand", as requested by the String meter. The inline function approach is clean and simple. When the String meter is updated, it asks for the result and uses it.
If you use Update(), you will get at least one execution that can't possibly return a valid result, as when the Lua Script measure is executed the first time on load / refresh, there can't be any value for the WebParser measure. So even with UpdateDivicer=-1 you will get one invalid / empty response. You can set UpdateDivider=-1 and Disabled=1 on the Lua measure, and have a FinishAction on the WebParser parent enable and update it, but seems like a lot of effort.
There are lots of ways you can get this result, but I feel like what I did is the simplest and uses the least code.
Then the result is only asked for and set on each UpdateRate of the parent WebParser measure, and no DynamicVariables is needed on the String meter. Same result, slightly more efficient.
Only problem with this is i have 4 other meters that will be calling the convert, so your previous answer would probably be the best bet
Didn't realize Inline lua was only release in november.. was running rainmeter 4.0 all fixed thanks
Great. I do encourage you to stay current with at least the latest "release" version of Rainmeter, and to be honest I strongly encourage staying current with the latest beta version. Almost everything I do in helping here on the forums will assume that at a minimum you have the latest release, and while I will try to warn, I will use features from the latest beta if I think they help.