Right, by "blocking" I mean that the entire Lua is executed in a single Rainmeter Update cycle.
If you have a Lua like this:
Code: Select all
for a = 1, 100 do
SKIN:Bang('!SetOption', 'MeterCount', 'Text', 'Count is: '..a)
You might see the meter "flicker" a bit, but basically it will always be "100" All of the bangs will be executed, but they will all happen in the same Update cycle of the skin, as fast as your computer can execute them, which is really, really, fast. So it will increment the value of "a", send the Text option to the meter, update the meter and redraw the skin. It will do that 100 times, as fast as your computer will go (again, very fast) and end up at "100", where it will wait for the next skin Update cycle to start and begin again.
While that loop is executing, nothing else in the skin will happen, and the skin will be unresponsive to the mouse.
If you were to change that 100 to 1000000, the skin would become entirely unresponsive to any mouse actions, because it is "blocked" by the Lua script. Windows will treat it as a threat and kill Rainmeter entirely.
It isn't that each and every bang you send to the skin doesn't happen when you do it in a for / next loop in Lua, they all do. It's just that they all happen "at once" in a sense, or more accurately, "one after the other, as fast as possible".
Now you might think that you can beat that by building in some kind of "sleep" in the Lua for / next loop, but that won't work. It will just make the skin even more "unresponsive" and cause Windows to hate it even more. The skin will be unresponsive for the entire duration of the Lua Update() function.
Think of it this way. The skin passes control to the Lua script when the Script measure is executed. The skin will then sit, entirely unresponsive, until the script is finished and "returns". Then the skin regains control, and everything that the script told Rainmeter to do will all be done at once, one after the other, as fast as your computer will go.