[Suggestion] Assigning a number to a meter

[eclectic-tech]

Test my code instead...

Nice script! I can see this helping with referencing repeating sections.

I hope you don't mind that I modified your test skin to allow entering a section "Test Name"; a sample rmskin is attached.

sectionindex.png

When I have some time, I hope to look at using this script for other procedures as well.

Nice work!

[Yincognito]

Nice script! I can see this helping with referencing repeating sections.

I hope you don't mind that I modified your test skin to allow entering a section "Test Name"; a sample rmskin is attached.
sectionindex.png
When I have some time, I hope to look at using this script for other procedures as well.

Nice work!

Yeah, no worries, you can modify the test skin any way you like ... that's why it's a test skin, right?
So by all means, feel free to play with it and put it to work, and if you have suggestions don't hesitate to mention them. What I would like is to see the script work in an actual usage scenario (as opposed to a test one) in order to see if there are any possible drawbacks. Personally, I doubt there would be (besides the slightly "obfuscated" syntax of inline Lua), since such scripts are blazingly fast when it comes to string searching and table (i.e. "array") manipulation, as you'd expect from a programming language that does most of the work in memory, but it would nevertheless be interesting to see the actual result. Unfortunately, most if not all my skins are already written, so replacing the classic method with this one is more work than benefit, but for skins about to be written it surely is a feasible option.

I'm glad you like it, as always it means a lot coming from you.

[Yincognito]

By the way, just a thought: to avoid lenghtier or unfamiliar inline Lua syntax, one could "simulate" a "built-in" variable like #CURRENTSECTIONINDEX# by doing something like this in the [Variables] section, taking advantage of escaping literal variables (including the nested ones):

Code: Select all

[Variables]
CURRENTSECTIONINDEX=[&Script:SectionIndex('[#*CURRENTSECTION*]',[#*Occurrence*])]
Occurrence=''last''
;Occurrence=3

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

---Measures---

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

[MeasureTest3Test56Test13Test2]
Measure=Calc
Formula="#CURRENTSECTIONINDEX#"
UpdateDivider=-1
DynamicVariables=1

[MeasureTest14Test2Test27Test101T]
Measure=Calc
Formula="#CURRENTSECTIONINDEX#"
UpdateDivider=-1
DynamicVariables=1

---Meters---

[MeterTest]
Meter=String
FontFace=Consolas
FontColor=255,255,255,255
SolidColor=47,47,47,255
Padding=5,5,5,5
FontSize=16
AntiAlias=1
MeasureName=MeasureTest3Test56Test13Test2
MeasureName2=MeasureTest14Test2Test27Test101T
Text="CURRENTSECTIONINDEX of MeasureTest3Test56Test13Test2    = %1#CRLF#CURRENTSECTIONINDEX of MeasureTest14Test2Test27Test101T = %2"
DynamicVariables=1

Notice how one can now actually use #CURRENTSECTIONINDEX# in the measures (or meters, or any section, for that matter) and also that you need to ''double quote'' (i.e. add another pair of quotes besides the original Lua style apostrophes) the string-like 'first' or 'last' parameters if you declare them as variables, because of the way that Rainmeter strips the beginning and ending single/double quotes from an option. Of course, one could just use the desired occurence directly in the CURRENTSECTIONINDEX variable (like CURRENTSECTIONINDEX=[&Script:SectionIndex('[#*CURRENTSECTION*]','last')], or CURRENTSECTIONINDEX=[&Script:SectionIndex('[#*CURRENTSECTION*]',3)]), if he only wants to use a certain occurence of an index every time...

P.S. To avoid having slight inconveniences when the 2nd parameter of the function is a string like 'first' or 'last', I could use numbers like 0 or -1 (otherwise "invalid" in this context) to have the meaning of "first occurrence" or "last occurrence".

P.S.2. This brings me to a minor issue in my script, where if the 2nd parameter is a numerical string like '3' or '5', the function would not yield the correct result (because in this case it expects the parameter to be a plain number). This is easily solved by converting such a "stringified" index to a number, i.e. modifying the last line of the function to:
return indexes[tonumber(occurrence)] or '0'
I will correct this in my earlier posts ASAP.

[Yincognito]

Couldn't help it, so I tested this on an actual usage scenario, like parsing a hypothetical JSON using WebParser measures...

Source.json, placed in the @Resources subfolder of the current skin (I parsed a local file, as it was easier, taking this sample JSON from Wikipedia):

Code: Select all

{
  "firstName": "John",
  "lastName": "Smith",
  "isAlive": true,
  "age": 27,
  "address": {
    "streetAddress": "21 2nd Street",
    "city": "New York",
    "state": "NY",
    "postalCode": "10021-3100"
  },
  "phoneNumbers": [
    {
      "type": "home",
      "number": "212 555-1234"
    },
    {
      "type": "office",
      "number": "646 555-4567"
    }
  ],
  "children": [],
  "spouse": null
}

Script.lua, placed in the Scripts subfolder from the @Resources folder of the current skin:

Code: Select all

function SectionIndex(section, occurrence)
  local indexes = {}
  for index in section:gmatch('%d+') do table.insert(indexes, index) end
  if occurrence == 'first' then occurrence = 1 elseif occurrence == 'last' then occurrence = #indexes end
  return indexes[tonumber(occurrence)] or '0'
end

SectionIndex.ini, i.e. the skin:

Code: Select all

[Variables]
; Inline Lua Usage: [&Script:SectionIndex(SomeSection,SomeOccurrence)]
; SomeSection     = the name of any section, enclosed by ' (apostrophes), like: 'Measure1' or 'Meter1'
; SomeOccurrence  = the desired occurrence of an index, like: 3 or 5 or 'first' or 'last'
; Section variables need to use their nested form, like: [&Script:SectionIndex('[#Section]',[#Occurrence])]

; OR

; Simulation of a CURRENTSECTIONINDEX "built-in" variable, "last" index scenario
CURRENTSECTIONINDEX=[&Script:SectionIndex('[#*CURRENTSECTION*]','last')]
; Alternative using inline Lua: [&Script:SectionIndex('[#CURRENTSECTION]','last')]

; Variables specific to this test skin:
ElementNumber=1

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

---Measures---

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

[Source]
Measure=WebParser
Url=file://#@#Source.json
RegExp=(?siU)^.*\{.*"firstName":(.*),.*"lastName":(.*),.*"isAlive":(.*),.*"age":(.*),.*"address":.*(\{.*\}),.*"phoneNumbers":.*(\[.*\]),.*"children":.*(\[.*\]),.*"spouse":(.*)\}$
UpdateRate=3600
FinishAction=[!UpdateMeasureGroup "SourceGroup"][!UpdateMeter *][!Redraw]
OnConnectErrorAction=[!UpdateMeasureGroup "SourceGroup"][!UpdateMeter *][!Redraw]
OnRegExpErrorAction=[!UpdateMeasureGroup "SourceGroup"][!UpdateMeter *][!Redraw]

[Element1]
Measure=WebParser
Url=[Source]
StringIndex=#CURRENTSECTIONINDEX#
UpdateDivider=-1
DynamicVariables=1

[Element2]
Measure=WebParser
Url=[Source]
StringIndex=#CURRENTSECTIONINDEX#
UpdateDivider=-1
DynamicVariables=1

[Element3]
Measure=WebParser
Url=[Source]
StringIndex=#CURRENTSECTIONINDEX#
UpdateDivider=-1
DynamicVariables=1

[Element4]
Measure=WebParser
Url=[Source]
StringIndex=#CURRENTSECTIONINDEX#
UpdateDivider=-1
DynamicVariables=1

[Element5]
Measure=WebParser
Url=[Source]
StringIndex=#CURRENTSECTIONINDEX#
UpdateDivider=-1
DynamicVariables=1

[Element6]
Measure=WebParser
Url=[Source]
StringIndex=#CURRENTSECTIONINDEX#
UpdateDivider=-1
DynamicVariables=1

[Element7]
Measure=WebParser
Url=[Source]
StringIndex=#CURRENTSECTIONINDEX#
UpdateDivider=-1
DynamicVariables=1

[Element8]
Measure=WebParser
Url=[Source]
StringIndex=#CURRENTSECTIONINDEX#
UpdateDivider=-1
DynamicVariables=1

---Meters---

[MeterElement]
Meter=String
FontFace=Consolas
FontColor=255,255,255,255
SolidColor=47,47,47,255
Padding=5,5,5,5
FontSize=16
AntiAlias=1
MeasureName=Element#ElementNumber#
Text="Element No. #ElementNumber# =#CRLF##CRLF#%1"
MouseScrollUpAction=[!SetVariable ElementNumber (Clamp((#ElementNumber#-1),1,8))][!UpdateMeter MeterElement][!Redraw]
MouseScrollDownAction=[!SetVariable ElementNumber (Clamp((#ElementNumber#+1),1,8))][!UpdateMeter MeterElement][!Redraw]
DynamicVariables=1

Packed version:

SectionIndex_1.0.0.rmskin

The result is according to the expectations: each [ElementN] measure is grabbing the N-th element in the JSON (didn't bother with further splitting the elements, as it plays no role in what I wanted to see). Not sure if I should stringify the function result for consistency with the '0' fail case, but one could do this by changing the last line of the function to return tostring(indexes[tonumber(occurrence)]) or '0'. Probably not needed, as generally Rainmeter doesn't need this kind of strict format, plus there might be some places like IfConditions or Conditional Operations that would need numbers to work, but just in case.

[Active Colors]

Yincognito,
Just getting to this. Sweeet! Works like a charm. Awesome work, really.


I have the only trouble with a section number 10. When I have it in my skin I get N times the same errors for not having a section with a number 0, where N stands for the amount of the same section names. The script works for the section 10 as intended but the log catches the mysterious 0 section.

Capture.PNG

I read about it in your message but I am not sure what would be the proper way of solving this issue. I tried both of the variants:
return tostring(indexes[tonumber(occurrence)]) or '0'
return indexes[tonumber(occurrence)] or '0'

If it matters, I used it here:

Code: Select all

[ObjDistance1]
Meter=Image
X=([ObjIcon[#CURRENTSECTIONINDEX]:XW])

Also, in case of having a section 11 while not having a section 1 the log will not populate any error for not having a mysterious section 1. Hence the problem appears only for not having a section 0.

[Yincognito]

Yincognito,
Just getting to this. Sweeet! Works like a charm. Awesome work, really.


I have the only trouble with a section number 10. When I have it in my skin I get N times the same errors for not having a section with a number 0, where N stands for the amount of the same section names. The script works for the section 10 as intended but the log catches the mysterious 0 section.
Capture.PNG
I read about it in your message but I am not sure what would be the proper way of solving this issue. I tried both of the variants:
return tostring(indexes[tonumber(occurrence)]) or '0'
return indexes[tonumber(occurrence)] or '0'

If it matters, I used it here:

Code: Select all

[ObjDistance1]
Meter=Image
X=([ObjIcon[#CURRENTSECTIONINDEX]:XW])

Also, in case of having a section 11 while not having a section 1 the log will not populate any error for not having a mysterious section 1. Hence the problem appears only for not having a section 0.

I'll take a look and probably solve it later on. For the moment I'm a bit busy with other stuff, but will get back to you later today.

[Yincognito]

Yincognito,
Just getting to this. Sweeet! Works like a charm. Awesome work, really.


I have the only trouble with a section number 10. When I have it in my skin I get N times the same errors for not having a section with a number 0, where N stands for the amount of the same section names. The script works for the section 10 as intended but the log catches the mysterious 0 section.
Capture.PNG
I read about it in your message but I am not sure what would be the proper way of solving this issue. I tried both of the variants:
return tostring(indexes[tonumber(occurrence)]) or '0'
return indexes[tonumber(occurrence)] or '0'

If it matters, I used it here:

Code: Select all

[ObjDistance1]
Meter=Image
X=([ObjIcon[#CURRENTSECTIONINDEX]:XW])

Also, in case of having a section 11 while not having a section 1 the log will not populate any error for not having a mysterious section 1. Hence the problem appears only for not having a section 0.

Ok, I had some time available now, and I took a look at it, by adding "logging" at every step of the way, both in Lua and Rainmeter, coupled with adding dynamic variables everywhere, just in case. This code reproduces the issue (it has nothing to do with a section 10 or anything like that):

Script.lua:

Code: Select all

function SectionIndex(section, occurrence)
  print('LUA > ', 'Section: ' .. section, ', Occurrence: ' .. occurrence)
  local indexes = {}
  for index in section:gmatch('%d+') do table.insert(indexes, index) end
  print('LUA > ', 'Indexes: ' .. unpack(indexes))
  if occurrence == 'first' then occurrence = 1 elseif occurrence == 'last' then occurrence = #indexes end
  print('LUA > ', 'Result: ' .. tostring(indexes[tonumber(occurrence)]))
  return tostring(indexes[tonumber(occurrence)]) or '0'
end

Test.ini:

Code: Select all

[Variables]
; Inline Lua Usage: [&Script:SectionIndex(SomeSection,SomeOccurrence)]
; SomeSection     = the name of any section, enclosed by ' (apostrophes), like: 'Measure1' or 'Meter1'
; SomeOccurrence  = the desired occurrence of an index, like: 3 or 5 or 'first' or 'last'
; Section variables need to use their nested form, like: [&Script:SectionIndex('[#Section]',[#Occurrence])]

; OR

; Simulation of a CURRENTSECTIONINDEX "built-in" variable, "last" index scenario
CURRENTSECTIONINDEX=[&Script:SectionIndex('[#*CURRENTSECTION*]','last')]
; Alternative using inline Lua: [&Script:SectionIndex('[#CURRENTSECTION]','last')]

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

---Measures---

[Script]
Measure=Script
ScriptFile=#@#Scripts\Script.lua
UpdateDivider=-1
DynamicVariables=1

---Meters---

[Background]
Meter=Image
W=300
H=300
SolidColor=255,0,0,255

[ObjIcon1]
Meter=Image
X=1
ImageName=#@#Images\a.png
DynamicVariables=1

[ObjDistance1]
Meter=Image
X=([&ObjIcon[#CURRENTSECTIONINDEX]:XW])
;X=([&ObjIcon[&Script:SectionIndex('[#CURRENTSECTION]','last')]:XW])
W=5
H=5
SolidColor=255,255,0,255
UpdateDivider=-1
OnUpdateAction=[!Log "RAINMETER > CURRENTSECTION: #CURRENTSECTION#"]
DynamicVariables=1

This code assumes you have an a.png image like the one below placed in @Resources\Images folder of your skin:

a.png

The Log makes it clear that this "error" happens before the Lua script or any Rainmeter meter update happens, and it only happens once per section. Everything else works fine, as you can see, so my guess is that this has something to do with Rainmeter's initial parsing of the skin code, when most of the things are not "initialized", thus probably assigned "0" by Rainmeter. It has nothing to do with the script (which works fine), nothing to do with the value returned by the script (you can return a fail safe value other than '0' and the 0 in the error will stay the same, so it's no connection between the two), and nothing to do with the section names (having a [ObjIcon0] somewhere and not seeing the error is just coincidence due to the 0 initially assigned to the inline option by Rainmeter in the first place).

I can't think of a perfect solution to this (yet), but some variants could be:
- disable/hide stuff until things get properly initialized
- have a conditional (condition?actioniftrue:actioniffalse) that handles the situation on refresh
- post a bug report in the appropriate forum section about this behavior and see what the devs say

I'll keep thinking about this later on today, maybe I'll come up with a better variant. So far all I can say is that "it's not my fault", LOL...

[Active Colors]

Ok, I had some time available now, and I took a look at it, by adding "logging" at every step of the way, both in Lua and Rainmeter, coupled with adding dynamic variables everywhere, just in case. This code reproduces the issue (it has nothing to do with a section 10 or anything like that):

Script.lua:

Code: Select all

function SectionIndex(section, occurrence)
  print('LUA > ', 'Section: ' .. section, ', Occurrence: ' .. occurrence)
  local indexes = {}
  for index in section:gmatch('%d+') do table.insert(indexes, index) end
  print('LUA > ', 'Indexes: ' .. unpack(indexes))
  if occurrence == 'first' then occurrence = 1 elseif occurrence == 'last' then occurrence = #indexes end
  print('LUA > ', 'Result: ' .. tostring(indexes[tonumber(occurrence)]))
  return tostring(indexes[tonumber(occurrence)]) or '0'
end

Test.ini:

Code: Select all

[Variables]
; Inline Lua Usage: [&Script:SectionIndex(SomeSection,SomeOccurrence)]
; SomeSection     = the name of any section, enclosed by ' (apostrophes), like: 'Measure1' or 'Meter1'
; SomeOccurrence  = the desired occurrence of an index, like: 3 or 5 or 'first' or 'last'
; Section variables need to use their nested form, like: [&Script:SectionIndex('[#Section]',[#Occurrence])]

; OR

; Simulation of a CURRENTSECTIONINDEX "built-in" variable, "last" index scenario
CURRENTSECTIONINDEX=[&Script:SectionIndex('[#*CURRENTSECTION*]','last')]
; Alternative using inline Lua: [&Script:SectionIndex('[#CURRENTSECTION]','last')]

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

---Measures---

[Script]
Measure=Script
ScriptFile=#@#Scripts\Script.lua
UpdateDivider=-1
DynamicVariables=1

---Meters---

[Background]
Meter=Image
W=300
H=300
SolidColor=255,0,0,255

[ObjIcon1]
Meter=Image
X=1
ImageName=#@#Images\a.png
DynamicVariables=1

[ObjDistance1]
Meter=Image
X=([&ObjIcon[#CURRENTSECTIONINDEX]:XW])
;X=([&ObjIcon[&Script:SectionIndex('[#CURRENTSECTION]','last')]:XW])
W=5
H=5
SolidColor=255,255,0,255
UpdateDivider=-1
OnUpdateAction=[!Log "RAINMETER > CURRENTSECTION: #CURRENTSECTION#"]
DynamicVariables=1

This code assumes you have an a.png image like the one below placed in @Resources\Images folder of your skin:
a.png

The Log makes it clear that this "error" happens before the Lua script or any Rainmeter meter update happens, and it only happens once per section. Everything else works fine, as you can see, so my guess is that this has something to do with Rainmeter's initial parsing of the skin code, when most of the things are not "initialized", thus probably assigned "0" by Rainmeter. It has nothing to do with the script (which works fine), nothing to do with the value returned by the script (you can return a fail safe value other than '0' and the 0 in the error will stay the same, so it's no connection between the two), and nothing to do with the section names (having a [ObjIcon0] somewhere and not seeing the error is just coincidence due to the 0 initially assigned to the inline option by Rainmeter in the first place).

I can't think of a perfect solution to this (yet), but some variants could be:
- disable/hide stuff until things get properly initialized
- have a conditional (condition?actioniftrue:actioniffalse) that handles the situation on refresh
- post a bug report in the appropriate forum section about this behavior and see what the devs say

I'll keep thinking about this later on today, maybe I'll come up with a better variant. So far all I can say is that "it's not my fault", LOL...

Inserting a dummy 0 section eliminates the error appearance. I think it is fine and shouldn't break a skin or Rainmeter. I can't thank enough for making this. I appreciate it. The lua code is actually pretty elegant and simple, without any complication, and making a custom variable by inserting inline lua is just genius. Brilliant!

[Yincognito]

Inserting a dummy 0 section eliminates the error appearance. I think it is fine and shouldn't break a skin or Rainmeter. I can't thank enough for making this. I appreciate it. The lua code is actually pretty elegant and simple, without any complication, and making a custom variable by inserting inline lua is just genius. Brilliant!

Yeah, I wanted to mention inserting a dummy 0 section at the time of replying earlier, but didn't, cause it seemed worse than the other choices (it forces you to do something not really needed). Point is, apart from Rainmeter's process of reading the skin code which can't really be changed and it is what it is (similar example: having to initially disable some WebParser measures in order to not get errors when they belong to a longer chain of events involving other dynamic WebParser measures - I'm sure you know what I'm talking about), this should not happen, as all the code is fine and works. Now I have more time and will continue to investigate whether a more reasonable variant to solve this exists.

I'm glad you like the solution though. I probably wouldn't have posted this if another skin I wanted to work properly didn't force me to get familiar with Lua recently, LOL. The rest (i.e. using a custom variable to fake a "built-in" variable with the help of inline Lua and nested syntax) is just a bit of out-of-the-box thinking, incidentally also influenced by my weather skin forcing me to get familiar with the nested syntax and its advantages/disadvantages last year.

I will keep you posted if I find some solution that looks better in this specific case. My last reply was a bit rushed and didn't have proper time to think about a good workaround.

[Yincognito]

I think it is fine and shouldn't break a skin or Rainmeter.

Ok, I found the culprit, but not sure if I should be happy about it: it's Rainmeter's formula parser. For example, this:

X=([&ObjIcon[#CURRENTSECTIONINDEX]:XW])

will produce the stupid error on skin refresh, but this (notice the lack of round brackets):

X=[&ObjIcon[#CURRENTSECTIONINDEX]:XW]

will not. So, as long as you don't add, subtract, multiply, divide, etc. the thing, you can skip the round brackets and lo and behold, it's error free, LMAO. Obviously, on a superficial look (not dwelling into technicalities) this doesn't make any sense, but...

I remember talking a while ago with Brian about other slight (and somewhat related) inconveniences regarding Rainmeter's formula parser (possibly in conjunction with the nested syntax, but I'm not sure it was that too), and, as far as I recall, there wasn't what you'd call a nice solution then either, so I'm afraid we have to live with it. There is this small possibility that one of the developers will come up with a workaround that escaped us, but I wouldn't count on it...

P.S. This is unfortunate, because I too like to use round brackets in such options, even though there isn't any operation going on - just in case I need to insert one later on in the skin development process.

EDIT: I believe this behavior has something to do with the Important Final Note section from the Inline Lua Notes in the manual. Apart from the error appearing only in a formula, the fact that initial errors due to the order of operations in Rainmeter and Lua at skin refresh time is quite comprehensively alluded to. This is pretty much what happens here. All in all, it's just an initial error with 0 impact on the actual result and behavior, at least starting with the time the skin has finished running its refresh mechanism and is "completely" loaded.