Meters Auto-Adjust to container's height (?)

[RicardoTM]

You know best what you have in your skin. When it comes to the function I wrote, that can be customized differently, e.g get the the last 2 or 3 chars from the section name, etc. It's meant to help others, not to have its code set in stone, you know...

I just didn't quite understand the formula part, but I have to play more with it and read more on the thread you linked. For now I don't think changing where the index value is located at would solve the problem anyway.

[Yincognito]

I just didn't quite understand the formula part, but I have to play more with it and read more on the thread you linked.

If you mean the formula part in the .lua script, i.e. string.gsub(formula, '<x>', tostring(indexes[tonumber(occurrence)] or '0')), it just replaces <x> with the value of the indicated index in case you want to do math with that index directly when you call the function. It probably isn't absolutely needed, but it was mentioned in that thread and I thought it was a nice "feature" to have (though a bit useless since Rainmeter can do math too with the function result afterwards anyway).

[RicardoTM]

If you mean the formula part in the .lua script, i.e. string.gsub(formula, '<x>', tostring(indexes[tonumber(occurrence)] or '0')), it just replaces <x> with the value of the indicated index in case you want to do math with that index directly when you call the function. It probably isn't absolutely needed, but it was mentioned in that thread and I thought it was a nice "feature" to have (though a bit useless since Rainmeter can do math too with the function result afterwards anyway).

Oh, so that means the formula could be included directly instead of letting rainmeter do de math, so something like (<x>-1). Yah, it could be useful, not much in this case tho lol. But it gave me an idea, sadly I already implemented the groups I mentioned on my earlier post.

I was thinking I could use a different formula for the Y position on the shape meters. That have the s,

They go like sensor1 and sensor1s, which would be index 1 and 2, so I could simple add + 1 to the formula so it counts it as index 2.

No I think it would have to be something different.

Since sensor6 and sensor6s would be indices 11 and 12, so the formula should go times 2 minus 1 instead of only plus 1.

I gotta think about it.

EDIT.

Alright I tested and it works perfectly. I didn't understand the occurrence part at first. I thought first meant like the index was the first character and last the last. But it is the first occurrence of a number, so no matter where the number is, it will return it. So if you have more than one number on a section you can choose which number an so on. That's pretty neat.

So I only needed to do it like this: y=(Round([FGap]*([&S:sectionIndex('[#CurrentSection]','first','((<x>*2)-1)')]))-Round([FGap]*(([&S:sectionIndex('[#CurrentSection]','first','((<x>*2)-1)')])-1)))R
for the String meters (Sensor1,Sensor2 and so on).

and like this: y=(Round([FGap]*([&S:sectionIndex('[#CurrentSection]','first','(<x>*2)')]))-Round([FGap]*(([&S:sectionIndex('[#CurrentSection]','first','(<x>*2)')])-1)))R
for the shape meters (Sensor1s,Sensor2s and so on).

I guess I could also add the whole thing to the formula part like ([&FGap]*(<x>*2)).

Pretty neat function you made

[Yincognito]

No I think it would have to be something different.

Since sensor6 and sensor6s would be indices 11 and 12, so the formula should go times 2 minus 1 instead of only plus 1.

Something like this?

Code: Select all

function SectionIndex(section, occurrence, formula)
  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 tostring(SKIN:ParseFormula(string.gsub(formula, '<x>', tostring(indexes[tonumber(occurrence)] or '0')))) or '0'
end

function SectionSuffix(section)
  -- short operational version (less clear):
  ------------------------------------------
  local m, s = section:match('%d+s?$') and 2 or 1, section:match('%d+$') and 1 or 0; return tostring(SectionIndex(section, 'last', '<x>') * m - s)

  -- long conditional version (more clear):
  -----------------------------------------
  -- if section:match('%d+s$') then return tostring(SectionIndex(section, 'last', '<x>') * 2 - 0)
  -- elseif section:match('%d+$') then return tostring(SectionIndex(section, 'last', '<x>') * 2 - 1)
  -- else return tostring(SectionIndex(section, 'last', '<x>') * 1 - 0)
  -- end
end

Code: Select all

[Variables]

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

---Measures---

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

---Meters---

[Result7Text6]
Meter=String
Y=0r
FontColor=255,255,255,255
FontFace=Consolas
FontSize=16
Padding=5,5,5,5
AntiAlias=1
Text=Section Index 6  = [&Script:SectionSuffix('[#CURRENTSECTION]')]
UpdateDivider=-1
DynamicVariables=1

[Result7Text6s]
Meter=String
Y=0R
FontColor=255,255,255,255
FontFace=Consolas
FontSize=16
Padding=5,5,5,5
AntiAlias=1
Text=Section Index 6s = [&Script:SectionSuffix('[#CURRENTSECTION]')]
UpdateDivider=-1
DynamicVariables=1

[Result7Text6n]
Meter=String
Y=0R
FontColor=255,255,255,255
FontFace=Consolas
FontSize=16
Padding=5,5,5,5
AntiAlias=1
Text=Section Index 6n = [&Script:SectionSuffix('[#CURRENTSECTION]')]
UpdateDivider=-1
DynamicVariables=1

Section Suffix.jpg

The "X and Y or Z" parts are equivalent to "X ? Y : Z" in Rainmeter, in other words they're Lua's version of ternary operators aka conditionals.

EDIT: Just saw your edit. Well, guess I wrote another neat function, lol (in case you wanted to avoid different syntax in the Y for the <x>$ and <x>s$ sections). In order to use a common style, that is.

[RicardoTM]

Something like this?

Section Suffix.jpg
The "X and Y or Z" parts are equivalent to "X ? Y : Z" in Rainmeter, in other words they're Lua's version of ternary operators aka conditionals.

EDIT: Just saw your edit. Well, guess I wrote another neat function, lol (in case you wanted to avoid different syntax in the Y for the <x>$ and <x>s$ sections). In order to use a common style, that is.

Yup, that's pretty neat as well but pretty especific tho, I think "suffix" could be added (so it would be SectionSuffix(section,suffix)) so one could choose what suffix to take into account.

That way it could be used on any special case, like if someone had Sensor6 Sensor6s and Sensor6n and needed to count Sensor6n as well the result should be 11, 12, and 13. That would need the last *m-s formula to change to *m+s though.

By the way, yah, I used the "X and Y or Z" a lot on my raincolors.lua script (actually I think I only needed "or").

Edit. Just to add an example, on one of the Tutorial pages I have re made the gauge icons so they use the colorable icons I used on HSLiders.

To construct a complete gauge it requires 3 image meter + 2 string meters + 1 shape meter , So I have them as G1, G1B. G1G, G1F,, G1V and G1T. (Background, Gradient, Foreground, Value and Title).

Luckily on this precise construct they don't need to be part of anything since their position is relative to G1 anyway, so all other meters don't need to be counted as indices.

[Yincognito]

Yup, that's pretty neat as well but pretty especific tho, I think "suffix" could be added (so it would be SectionSuffix(section,suffix)) so one could choose what suffix to take into account.

That way it could be used on any special case, like if someone had Sensor6 Sensor6s and Sensor6n and needed to count Sensor6n as well the result should be 11, 12, and 13. That would need the last *m-s formula to change to *m+s though.

By the way, yah, I used the "X and Y or Z" a lot on my raincolors.lua script (actually I think I only needed "or").

Well, your example was specific too, so I wrote it based on that - up to you to improve or add to it if needed. Also, it's unclear what index order would s and n need to have in general, I suppose it won't be alphabetical or based on their char code, but rather user / skin specific, thus open to interpretation.

In the end, it was just an example on how to do it without affecting the original function and allowing usage in a common style via the same syntax, the rest is in fact quite specific from case to case (your Gauges might need one interpretation, another skin or suite might need another). Bar the greater flexibility that the formula offers at the cost of different syntax (not that much of a drawback to have 2 styles instead of just 1, just saying), the obvious alternative is to use plain indices without trying to index letters (or even using s6 instead of 6s if / when possible), but of course it's too late for that now in your case.

Yeah, I suspected you knew about the X and Y or Z, that part was just in the unlikely case you didn't yet (and potentially for whatever future readers, to explain a bit how the code works).

[RicardoTM]

Well, your example was specific too, so I wrote it based on that - up to you to improve or add to it if needed. Also, it's unclear what index order would s and n need to have in general, I suppose it won't be alphabetical or based on their char code, but rather user / skin specific, thus open to interpretation.

In the end, it was just an example on how to do it without affecting the original function and allowing usage in a common style via the same syntax, the rest is in fact quite specific from case to case (your Gauges might need one interpretation, another skin or suite might need another). Bar the greater flexibility that the formula offers at the cost of different syntax (not that much of a drawback to have 2 styles instead of just 1, just saying), the obvious alternative is to use plain indices without trying to index letters (or even using s6 instead of 6s if / when possible), but of course it's too late for that now in your case.

Yeah, I suspected you knew about the X and Y or Z, that part was just in the unlikely case you didn't yet (and potentially for whatever future readers, to explain a bit how the code works).

I just mention it because it could be a nice and more general neat function, but honestly the sectionIndex function is already general and pretty good since it supports the formulas already, so the other function (in my case) is not necessary. The original function can be applied to specific cases anyway. In my case I already had different styles for both kind of meters since the normal ones are strings and the s ones are shapes.

Name them as SensorS1 was not possible (well not impossible either lol), but Sensor1s worked better to use "[#CurrentSection]s" but yeah it's too late for that, since that naming comes from 1.0 version lol

Just to add something educational for future readers as well, here's what "x or y and z" aka logical operators are: https://www.lua.org/manual/5.1/manual.html#2.5.3

[Yincognito]

I just mention it because it could be a nice and more general neat function

I'm all for being as general as possible without sacrificing flexibility, so if you have suggestions, I'm all ears (or eyes).

That being said, it's difficult to cover all potential specific cases related to how non numbers would be indexed. As much as I like "one size fits all" solutions via complete flexibility, there are cases that do depend on skin implementation and where skin designers would have different expectations on what the function output should eventually be, and my 'occurrence' and 'formula' parameters were added precisely for that reason.

As you just said, they already offer reasonable freedom in choosing how the output looks like, and I'm afraid that more adjustments on that front would make the function a bit too specific to serve as a general one that anyone can use as desired.