Creating a range/floating bar graph

[Falxon]

....
But even if this does work, I'd be tempted to, instead of enabling the measure by setting their Disabled option to 0, use the !EnableMeasure bang. For instance instead of [!SetOption ExampleMeasureUsingWebParser Disabled 0] a much more elegant solution is something like [!EnableMeasure "ExampleMeasureUsingWebParser"].
Don't misunderstand me, your solution (setting the Disabled option to 0) definitely works, but at least for me, this seems a much more elegant solution.

Thanks again for the timely response and sorry if I keep bothering you! I just tried that syntax and it doesn't seem to work.

Code: Select all

[mWeather]
Measure=WebParser
UpdateRate=600
ProxyServer=/none
Url=SOME_URL
RegExp=(?siU)^(.*)$

; This line works
FinishAction=[!SetOption mCurrent.Icon Disabled 0] [!SetOption mCurrent.Text Disabled 0] [!SetOption mCurrent.Temp Disabled 0]

; But this line does not!
FinishAction=[!EnableMeasure "mCurrent.Icon"] [!EnableMeasure "mCurrent.Text"] [!EnableMeasure "mCurrent.Temp"]

So I pulled the source code down and compiled it. On further digging, this appears to be a bug. I have a patch that fixes it, but am doing more testing before submitting a pull request.

EDIT: The pull request is made - https://github.com/rainmeter/rainmeter/pull/231. Hoping someone checks it out and reviews.

[balala]

Thanks again for the timely response and sorry if I keep bothering you! I just tried that syntax and it doesn't seem to work.

Firstly: what the URL is? Url=SOME_URL doesn't make too much sense. What SOME_URL is? Is it a variable? If so, the option should be Url=#SOME_URL#.
Secondly: there is nothing which should avoid those !EnableMeasure bangs to work. They are always working, I applied such bangs many times and they always worked, so don't know what to say. Maybe post the whole code.

[Falxon]

Firstly: what the URL is? Url=SOME_URL doesn't make too much sense. What SOME_URL is? Is it a variable? If so, the option should be Url=#SOME_URL#.
Secondly: there is nothing which should avoid those !EnableMeasure bangs to work. They are always working, I applied such bangs many times and they always worked, so don't know what to say. Maybe post the whole code.

The SOME_URL was just text I typed in to remove the real URL from posting. It works fine now with the updated and recompiled C++ code. The problem is as follows and is a code bug:

• If you use [!SetOption MEASURE_NAME Disabled 0] the measure is enabled REGARDLESS of whether that measure uses DynamicVariables=1.

• If you use [!EnableMeasure MEASURE_NAME] the measure is enabled ONLY if that measure uses DynamicVariables=1. Otherwise it fails silently.
  You can test this quite easily with even the latest Rainmeter beta for example.

I have stepped through the code several times with the debugger and it is 100% reproducible. In fact, the SetOption function purposefully makes a call to force DynamicVariables to 1. There is even a comment in the code that calls it out. But someone left the equivalent code out for the EnableMeasure function. That's why I submitted the pull request for inclusion into the code.

[balala]

The SOME_URL was just text I typed in to remove the real URL from posting.

Alright in this case.

It works fine now with the updated and recompiled C++ code.

Where do you need a C++ code for a skin?

• If you use [!SetOption MEASURE_NAME Disabled 0] the measure is enabled REGARDLESS of whether that measure uses DynamicVariables=1.

...

I have stepped through the code several times with the debugger and it is 100% reproducible. In fact, the SetOption function purposefully makes a call to force DynamicVariables to 1. There is even a comment in the code that calls it out.

Exactly: https://forum.rainmeter.net/viewtopic.php?f=5&t=23050&p=121728#p121728

• If you use [!EnableMeasure MEASURE_NAME] the measure is enabled ONLY if that measure uses DynamicVariables=1. Otherwise it fails silently.
  You can test this quite easily with even the latest Rainmeter beta for example.

I disagree here. The !EnableMeasure bang enables the measure regardless if the dynamic variables are set or not.

[Falxon]

Where do you need a C++ code for a skin?

Exactly: https://forum.rainmeter.net/viewtopic.php?f=5&t=23050&p=121728#p121728

I disagree here. The !EnableMeasure bang enables the measure regardless if the dynamic variables are set or not.

So you probably missed my earlier post with a link to the pull request. When I say C++ code, I mean Rainmeter itself. As quoted in your link the setoption function does a virtual dynamicvariables setting, but the enablemeasure function does not - it is an omission in the code.

I'm not sure if you're running the non-beta, but on the latest beta, the enablemeasure function is 100% non-functional without that code change if dynamicvariables=1 is not set. Since the documentation does not state that DynamicVariables=1 is required, and since setoption works differently, this is a code issue.

But at the end of the day, once that pull request is merged, the behavior will work and be consistent, so I'm not expecting much push-back to it.

[jsmorley]

So you probably missed my earlier post with a link to the pull request. When I say C++ code, I mean Rainmeter itself. As quoted in your link the setoption function does a virtual dynamicvariables setting, but the enablemeasure function does not - it is an omission in the code.

I'm not sure if you're running the non-beta, but on the latest beta, the enablemeasure function is 100% non-functional without that code change if dynamicvariables=1 is not set. Since the documentation does not state that DynamicVariables=1 is required, and since setoption works differently, this is a code issue.

But at the end of the day, once that pull request is merged, the behavior will work and be consistent, so I'm not expecting much push-back to it.

Sorry to disagree with you on that...

I'm not sure I agree with the reasoning. There is nothing about !EnableMeasure or !UnpauseMeasure or the group variants that implies DynamicVariables. !SetOption is a special case that by design makes a measure dynamic for ONE update, so it can "see" the change that you make. I don't think that the case that using !SetOption to change the value of Enabled implies or requires that !EnableMeasure also makes a measure dynamic for ONE update, I don't really see the value in that. Nothing about the measure is changed, why is it important that the act of enabling it force dynamic variables? If you need a measure to be dynamic, make it dynamic.

I think you will find that having one skin author who basically says "I don't want to work the way Rainmeter works, change this just for me" may not get the most excited response...

I may be missing something here, I didn't follow the entire thread closely, and I don't think I'm opposed in principle, but then I haven't thought through any possible backwards compatibility issues. I just question if this is something that is really "needed" by the majority of authors, and really makes sense in the context of how things work.

Let's let Brian take a look at this and weigh in.

[eclectic-tech]

I have always used these bangs:

FinishAction=[!EnableMeasure SomeMeasureName][!UpdateMeasure SomeMeasureName]

Enabling a disabled measure does not update it unless you add an update bang or use DynamicVariables=1 on the measure.

[jsmorley]

I have always used these bangs:

FinishAction=[!EnableMeasure SomeMeasureName][!UpdateMeasure SomeMeasureName]

Enabling a disabled measure does not update it unless you add an update bang or use DynamicVariables=1 on the measure.

I'm not sure I see any direct correlation between !UpdateMeasure and DynamicVariables with this. If you !EnableMeasure a measure, it will update the very next time that it normally would if it didn't ever have Disabled on it. It will get or have whatever value it would get or have if didn't ever have Disabled on it. Mind you, if the measure in question is using something like a [SectionVariable] that is created or updated in the measure that has the FinishAction on it, you would need DyanmicVariables=1 on it, but you would in any case if you are using a dynamic value like a [SectionVariable].

I'm just struggling to understand why using !EnableMeasure on some measure should have anything to do with DynamicVariables in and of itself. !SetOption really must force the measure to re-evaluate all option values when it is used, because by the very nature and purpose of !SetOption, you are changing some value. !EnableMeasure doesn't change any values of any options on the measure. All it really does is tell the code to ignore any Disabled option going forward.

[balala]

Enabling a disabled measure does not update it unless you add an update bang or use DynamicVariables=1 on the measure.

Agree with jsmorley. If an initially disabled measure is enabled, even if it has a DynamicVariables=1 option added, it is not updated implicitly when enabled. Me personally can't get this to work this way. It is immediately updated only if an [!UpdateMeasure "SomeMeasure"] bang is used.
Did you figure out something else?

[eclectic-tech]

Agree with jsmorley. If an initially disabled measure is enabled, even if it has a DynamicVariables=1 option added, it is not updated implicitly when enabled. Me personally can't get this to work this way. It is immediately updated only if an [!UpdateMeasure "SomeMeasure"] bang is used.
Did you figure out something else?

Yes, my point was simply that enabling a measure does not update it's value, so I usually use the enable and update bangs together.