[Feature Request] FOR / WHILE Measure

[Yincognito]

I know that this will probably not be deemed as necessary by the developers, but I'll just put it here for reference...

Currently, if one wants to do various things in a FOR / WHILE loop, the preferred choice is to implement this in Lua. In plain Rainmeter code, it's possible too, but in a limited and "hacky" way, via a "self updating measure" that will update itself as long as some condition(s) are met and eventually cease updating itself and exit the "loop" once the said condition(s) are not met anymore, something like:

Code: Select all

[SomeMeasure]
Measure=...
...
IfCondition=(SomeConditionsThatKeepTheLoopRunning)
IfTrueAction=[DoWhateverStuffAndProgressTowardsNotMatchingTheAboveConditions][!UpdateMeasure SomeMeasure]
IfFalseAction=[OptionallyDoWhateverStuff]
IfConditionMode=1
DynamicVariables=1

The problem with this is that, because of the particularities of Rainmeter's update system, the process is slow enough to result in a crash if by any chance the things and the number of times the things are done in the "loop" take longer than the time until the next "default" update of the said measure (typically, about 300 simple iterations are possible if the measure is by default updated once every 1000 ms), not to mention the fact that the logic must be carefully thought to avoid an infinite cycle of updating the measure.

So, my proposal is to have a dedicated measure to do that and in essence running whatever actions / bangs corresponding to an iteration as well as the loop itself from the internal C++ code (similar to how Lua is doing). The syntax of such a measure could be similar to the Script one or even the PowershellRM plugin or the ActionTimer one (by the way, can one do a FOR in an ActionTimer measure, how about a WHILE?):

Code: Select all

[WhileMeasure]
Measure=While
Actions=[StuffToDoDuringAnIterationHere]
While=(ConditionsToKeepIteratingHere)
...other possible options here...

Choosing a "while" system and naming over a "for" one has the additional benefit of not being restricted to a fixed number of iterations where an "index" is always less than a "count" and similar, but allows "personalizing" the condition(s) accordind to needs. Not sure string / regex conditions could be possible, but wouldn't hurt to have them. Apart from the obvious benefits of such a measure, it could probably make some of the things Lua is used for more accessible to the regular user.

P.S. I guess a plugin to introduce this would be fine too, it doesn't have to be included in the main distribution right away. Feel free to discuss this or come up with arguments for or against such an addition.