eclectic-tech wrote:Any ideas?
While similar in nature, there are actually 2 issues here. 1 has to do with ActionTimer and 1 has to do will ALL actions in Rainmeter. However, both are parsing issues.
Things to keep in mind:
- During the update cycle (either on the first update, or on all updates if DynamicVariables=1), regular non-action options are read from an internal cache (basically raw strings). Once the option is read, our parser first replaces any regular #variables# with its value. Then any [section] variables are replaced with the referenced measure value. At this point the option will be fully parsed with all the variable substitutions done and the measure/meter does whatever it needs to with it.
- Actions on the other hand, work differently. We want the action to have the most up-to-date value from measures available when the action is executed, not when it is read during the update cycle. To achieve this, we do not parse [section] variables in actions on read - we do it when the action is executed. We do still parse regular variables normally though.
- Because of #2 above, to parse the new-style nested variables correctly, we need to hold off on parsing [#variables] in only actions since there is a chance of nesting regular variables with section variables (ie.
[#Var1[&Var2]]). This means that using this new style for regular variables makes these variables dynamic in actions just like regular section variables. This is one of the only differences between using the old style syntax vs. the new style syntax.
Back to the issues.
The problem is the Repeat and Wait options were not designed to accept anything other than 'raw' numbers. Using the old-style syntax for regular variables works just fine here because this variable style is ALWAYS replaced when the option is read (see #1 above). However, technically the
options are actions...so due to #2 above, any [section] variables are not replaced until the action is executed. Since the parser expected a number when building the action list and not a reference to a measure (ie. [MeasureName]), the repeat option would fail. Same with the Wait option. Nested variables failed because of #3 above.
For ALL actions:
This problem is more about "when" we replace section variables when an action is executed and has lead to the discovery of a very long standing bug that hasn't reared its ugly head until now. We have often encouraged users to completely replace a long series of bangs with a regular variable to make things more readable. This has always worked great since regular variables are always replaced when the action is read (see #1 above). However, due to #2, using this same method with a section variable is broken - but no one in their right minds would do something like this.
Code: Select all
String=[!Log "Hello World"]
You would expect this code to log the message "Hello World" to the log when the string meter was clicked. But it does not..with no error or anything. The reason this fails is because for actions, we expect the bang(s) to be in a specific format. We basically search for a
. Once found, we get the name of the bang, then replace any section variables after the bang name. Once done, then we execute the bang. So basically we are parsing the bang name first, then replacing and section variables in the parameters of the bang, then executing it. In the case above, when the meter is clicked, the text [MeasureString] is sent to the bang parser not the value that measure represents (see #2 and #3 above).
Anyway.... both of these issues should be fixed for the next beta. Thank you for reporting these issues!