Expected Behavior: [Bug] is equal to the value of [HelloWorld] right from the start, due to the substitution in [Hello] Actual Behavior: On skin refresh, this happens...
Bug.jpg
Sure, no errors pop up afterwards, but I mean... what the heck?!
You do not have the required permissions to view the files attached to this post.
Last edited by Yincognito on September 15th, 2020, 7:19 pm, edited 1 time in total.
When the skin is first parsed on refresh, when the measures and meters are being "built", the value of [Hello] is still 0, since it hasn't been executed during the first update cycle yet. So it doesn't correctly resolve the MeasureName value. As soon as it does, it will resolve correctly.
Skins do the following when loaded:
1) Parse all measures and meters, resolving all options with the current value of any variables or section variables.
2) Create the measures and meters.
3) Execute all measures.
4) Execute all meters.
The Bar meter will always bark if it has a missing or invalid MeasureName value when the skin is first loaded or refreshed.
jsmorley wrote: ↑September 15th, 2020, 4:58 pm
When the skin is first parsed on refresh, when the measures and meters are being "built", the value of [Hello] is still 0, since it hasn't been executed during the first update cycle yet. So it doesn't correctly resolve the MeasureName value. As soon as it does, it will resolve correctly.
The Bar meter will always bark if it has a missing or invalid MeasureName value when the skin is first loaded or refreshed.
Try this:
Substitute="^0$":"Hello","^3$":"Hello"
Huh, that's strange. I could swear it never happened to me again before, and I do all kinds of things like that. But then, maybe I didn't look better.
The workaround though begs a question: what if you actually need to replace 0 with some other text in such a code? You solve this start problem and then you have another one. I think.
EDIT:No, you're right, it makes sense. I'm just baffled I didn't knew or stumbled on this earlier.
Yincognito wrote: ↑September 15th, 2020, 5:48 pm
Huh, that's strange. I could swear it never happened to me again before, and I do all kinds of things like that. But then, maybe I didn't look better.
The workaround though begs a question: what if you actually need to replace 0 with some other text in such a code? You solve this start problem and then you have another one. I think.
Dunno. Guess you will need some other workaround for that scenario. We just can't get around the fact that computers can only do one thing at a time (in spite of how it may look) and that there has to be some kind of "order" that these things are executed in.
Yincognito wrote: ↑September 15th, 2020, 5:48 pmEDIT:No, you're right, it makes sense. I'm just baffled I didn't knew or stumbled on this earlier.
Well, not all meter types require or will complain about an initial missing or invalid MeasureName value. String, Image and Button don't care for instance. Not sure, but I suspect that any meter that requires a numeric input value, like Bar, Rotator, Line, Histogram, will.
jsmorley wrote: ↑September 15th, 2020, 5:53 pm
Dunno. Guess you will need some other workaround for that scenario. We just can't get around the fact that computers can only do one thing at a time (in spite of how it may look) and that there has to be some kind of "order" that these things are executed in.
Yeah, I now figured what's bothering me here: it's not the fact that measures are 0 before instantiated, as this is normal, like we discussed before about stuff being defaulted to 0. The issue is that when Rainmeter gets to the meter, it should have already got the needed value from the measure (which executed beforehand). This issue makes it look like the meter is parsed / executed first, which is by Rainmeter modus operandi, abnormal. Even if this was a parsing thing, where section variables are replaced when "seen", this section variable should have already got a value from literally the first thing in the skin, the measure.
EDIT: Just say your numbered edit, still trying to wrap my head around the order of things - which I thought I knew.
jsmorley wrote: ↑September 15th, 2020, 5:58 pm
Well, not all meter types require or will complain about an initial missing or invalid MeasureName value. String and Image don't care for instance. Not sure, but I suspect that any meter that requires a numeric input value will.
This better explains the behavior, and also explains why I didn't stumbled upon that, as I rarely use Bar meters (this one is from my audio skin, actually).
Yincognito wrote: ↑September 15th, 2020, 6:02 pm
This issue makes it look like the meter is parsed / executed first, which is by Rainmeter modus operandi, abnormal. Even if this was a parsing thing, where section variables are replaced when "seen", this section variable should have already got a value from literally the first thing in the skin, the measure.
EDIT: Just say your numbered edit, still trying to wrap my head around the order of things - which I thought I knew.
No, the meter is not "executed" first, however it is "created" as one of the first steps that Rainmeter does. The meter could care less at first what the "value" of the measure defined in MeasureName is, but it DOES care that MeasureName exists.
jsmorley wrote: ↑September 15th, 2020, 6:05 pm
No, the meter is not "executed" first, however it is "created" as one of the first steps that Rainmeter does. The meter could care less at first what the "value" of the measure defined in MeasureName is, but it DOES care that MeasureName exists.
Quick question: will an instantiated (in the [Variables] section) variable instead of the measure solve the issue? I had to use the measure since a variable coming from a formula, like mine, isn't resolved to a single numerical value (yet - or maybe I'm missing something there as well) when used as a regex quantifier, like {#Variable#}, where #Variable# is actually (4-#OtherVariable#).
I'm not sure you understand what I mean, and posting a more complex code won't help.
Yincognito wrote: ↑September 15th, 2020, 6:14 pm
Quick question: will an instantiated variable instead of the measure solve the issue? I had to use the measure since a variable coming from a formula isn't resolved (yet - or maybe I'm missing something there as well) when used as a regex quantifier, like {#Variable#}.