mmxiv wrote: ↑April 8th, 2021, 7:15 pmso, I'm looking for a solution that will update measure2 and meter1 ONLY ONCE either the condition is "0" or "> 0". So measure2 and meter1 MUST be updated whenever the condition changes, but only once in any case. And ofc, measure2 MUST be disabled when condition is 0 and enabled when higher.
This does PRECISELY what you asked, but I'm not sure if it's what you want, since, because of that logical contradiction I mentioned: measure2 will update (just once) when the condition is "0", but any change to it won't happen since its enabling only comes (again, just once) when the condition is "> 0":
Take a look at the About window -> Skins tab for your skin and you'll see: measure2 gets enabled when it reaches 0, but its value will stay 0 (and not follow measure1's value), partly because of the negative update divider, partly because its enabling happens one step later in the process (i.e. when the condition is "> 0").
P.S. Disregard the loop and the logging, they are there just to illustrate what happens, e.g. simulate a working scenario. They can be easily removed once you get things working out as you want to. For that though, you'll have to decide and clarify the logical question above.
I removed the negative update divider from measure2 and meter1, since for the former it didn't make much sense as the measure gets disabled when it's not "> 0" and for the latter the meter has to update in order to receive the value from its associated measure (unless you want to manually update it by means of !SetOption, !UpdateMeter and !Redraw, which I don't think it's the case). I also set up the condition just for "> 0" (a numeric measure's value is 0 when it's disabled anyway): enable and update if True, disable and update (i.e. update the disabled state, not necessarily the value) if False.
Yincognito wrote: ↑April 8th, 2021, 7:46 pm
This does PRECISELY what you asked, but I'm not sure if it's what you want, since, because of that logical contradiction I mentioned: measure2 will update (just once) when the condition is "0", but any change to it won't happen since its enabling only comes (again, just once) when the condition is "> 0":
Take a look at the About window -> Skins tab for your skin and you'll see: measure2 gets enabled when it reaches 0, but its value will stay 0 (and not follow measure1's value), partly because of the negative update divider, partly because its enabling happens one step later in the process (i.e. when the condition is "> 0").
P.S. Disregard the loop and the logging, they are there just to illustrate what happens, e.g. simulate a working scenario. They can be easily removed once you get things working out as you want to. For that though, you'll have to decide and clarify the logical question above.
according to your code, when condition is "> 0", measure2 will keep updating but it should update only ONCE in any case until the change of measure1 occurs. The measure2 uses measure1 in its formula and according to it, it must be updated in both cases, 0 and above, in order to configure another meters in the configuration properly. Thus, it doesn't have to be updated on every update cycle of the configuration, as it only determines state of some meters, and the state depends on measure1.
mmxiv wrote: ↑April 8th, 2021, 8:20 pm
according to your code, when condition is "> 0", measure2 will keep updating but it should update only ONCE in any case until the change of measure1 occurs. The measure2 uses measure1 in its formula and according to it, it must be updated in both cases, 0 and above, in order to configure another meters in the configuration properly. Thus, it doesn't have to be updated on every update cycle of the configuration, as it only determines state of some meters, and the state depends on measure1.
Yeah, I get what you mean. Will post a code for this scenario as well. I suppose your negative update dividers in measure2 and meter1 are working towards the same goal, right?
I also think that updating a measure after it is disabled has not effect, but the update must be set one step earlier, like this: IfFalseAction=[!UpdateMeasure "measure2"][!DisableMeasure "measure2"]
Then it, when condition of measure1 changes to 0, it will firstly update measure2 and properly set what is in charge of it, then it will disable measure2.
In other words, i think that the Update bang will just be ignored if the measure is previously disabled.
I'm also not for a solution with Delays, that could probably work, for instance: IfTrueAction=[!EnableMeasure "measure2"][!UpdateMeasure "measure2"][Delay 1000][DisableMeasure "measure2"] or something like that, but not sure how it would work.
mmxiv wrote: ↑April 8th, 2021, 8:39 pm
I'm also not for a solution with Delays, that could probably work, for instance: IfTrueAction=[!EnableMeasure "measure2"][!UpdateMeasure "measure2"][Delay 1000][DisableMeasure "measure2"] or something like that, but not sure how it would work.
Something that I don't get is what was the purpose of your OnChangeAction? For the things you want, I don't believe it's suitable, and has the potential to mess up stuff, compared to your expecations. Was that inclusion for a reason, or you just tried to make stuff work and added it thinking it would solve the problem?
Yincognito wrote: ↑April 8th, 2021, 8:25 pm
Yeah, I get what you mean. Will post a code for this scenario as well. I suppose your negative update dividers in measure2 and meter1 are working towards the same goal, right?
It keeps your negative update dividers everywhere (assuming they had a purpose), updates and disables/enables stuff only once, whenever the source measure gets above 0 or reaches 0 again. It acts like a switch now, toggling between 0 and 1 (the first above 0 value) and doesn't update otherwise, though it stays enabled when above 0.
Not sure if it's what you're looking after, but who knows, maybe I understood correctly your goal...
Yincognito wrote: ↑April 8th, 2021, 8:53 pm
Something that I don't get is what was the purpose of your OnChangeAction? For the things you want, I don't believe it's suitable, and has the potential to mess up stuff, compared to your expecations. Was that inclusion for a reason, or you just tried to make stuff work and added it thinking it would solve the problem?
I thought it could, but for now I don't see a good solution using OnchangeAction here as not using [!UpdateMeasure "measure2"] in IfTrueAction produces the glitch while it has not effect in IfFalseAction since measure2 is being disabled.
Not. I think I've found a good solution, but I will try it later. Thanks for the help to you and balala, and now I know at least a bit more but this thing is pretty screwed up.
