eclectic-tech wrote: ↑August 25th, 2020, 12:25 am
Use the standard variable syntax in defining the variables in the [Variable] section:
Code: Select all
[Variables]
String1=""
String2="[MeasureToggler][MeasureToggler]\\"
;String1="string"
;String2="A [#String1] is made out of characters"
String3="[#String1] and it has a length."
String4="[#String2] Period."
When defined with the nested syntax, the variables are dynamically acted on when used in a bang, causing the error messages.
So the solution is to "skip" past nesting the empty string and start nesting only at the following level on the dependency chain, is that it? If so, I already thought of that - this is why I said that I might be able to find a workaround in my previous post. The thing is, I was hoping to avoid that - like I said, the empty string is just a valid string like any other, why can't it be nested?
That being said, I'm not sure about this, but maybe you didn't fully understand what happens:
- the errors appear
only if trying to nest an empty string (i.e.
"") variable or measure, it does
not happen for other strings, so I doubt the fact that the variables are causing the error messages just because "when defined with the nested syntax, the variables are dynamically acted on when used in a bang". If that was the case,
any nested variable used in a bang would cause these kind of errors, and this does not happen - I can nest and use the "\\" in a bang no problem
- I didn't have a typo in my previous post, therefore String1 is not the empty string like you posted in the code above, but either the empty string followed by a
single quote or two backslashes followed by a
single quote. This is why I tried to use the
[&MeasureToggler]" notation, so I can change the measure from nothing to \\ before that single quote and then update the other variables dynamically / automatically on the dependency chain
Other than that, your solution (well, actually hardcoding String1 as
" or
\\" and String2 as
\\" or
\\\\\\" when setting them with a bang and just start nesting once I got past the potential empty string variable) worked again, so thank you for that. I had to add a bunch of magic quotes to do that, but anyway, fortunately they were only two variables to be set, it would have been a disaster if they were more, as I would have got back where I started.
My conclusion is that this behavior should
NOT happen though and it's clearly something else going on here: it's not a dynamic variable problem, it's not a
[Variables] section problem, not a bang problem or anything like that, it's that the things mentioned happen only when trying to nest the empty string. Maybe Rainmeter internally just sets those nested variables to 'nothing' initially and then when trying to resolve them (aka "replace" them) with the actual value here - also 'nothing' in this case - the error about that "Can't replace a variable with itself" is spawned. Just a speculation, but well, stranger things happen...