It is currently March 29th, 2024, 7:07 am

[FEATURE REQUEST - Important] !UpdateVariables bang

Report bugs with the Rainmeter application and suggest features.
User avatar
jsmorley
Developer
Posts: 22628
Joined: April 19th, 2009, 11:02 pm
Location: Fort Hunt, Virginia, USA

Re: [FEATURE REQUEST - Important] !UpdateVariables bang

Post by jsmorley »

Yincognito wrote: August 22nd, 2020, 5:25 pm Hm, that's starting to make sense now, I guess. So I have to "tell" Rainmeter that it has to update on the line of dependency chain by using the nested form of referencing the nested elements? Sorry about asking about it, but while the escaping of variables is well documented in the manual and pretty clear, nesting variables is only documented at the level of nesting the names the variables, and not so much at the level of nesting their values...

I hope I make sense in the last phrase and you get where I'm going with this.
I do get you. Yes, you are on the right track.

When you "use" a [Variable], it basically goes and gets the string value of the variable, and puts it into the context of where you are using it. It then more or less works from the "inside out" resolving variables and formulas and section variables until it is done, then the entire thing is evaluated and "used". There may well be more than one "resolve" that is required when you have a variable that is referencing a variable, and if the "result", before that last resolution, creates a nested condition, then all the component parts will need to support nesting.

It's not really about nesting any "values", it's always about nesting the "names". The point is if the "value" of one thing is the "name" of another, that can certainly create a nesting condition.
User avatar
Yincognito
Rainmeter Sage
Posts: 7029
Joined: February 27th, 2015, 2:38 pm
Location: Terra Yincognita

Re: [FEATURE REQUEST - Important] !UpdateVariables bang

Post by Yincognito »

jsmorley wrote: August 22nd, 2020, 5:34 pm I do get you. Yes, you are on the right track.

When you "use" a [Variable], it basically goes and gets the string value of the variable, and puts it into the context of where you are using it. It then more or less works from the "inside out" resolving variables and formulas and section variables until it is done, then the entire thing is evaluated and "used". There may well be more than one "resolve" that is required when you have a variable that is referencing a variable, and if the "result", before that last resolution, creates a nested condition, then all the component parts will need to support nesting.
Yep, it's all clear now - my bad. I guess I should have paid a bit more attention to what was alluded to between the lines in the quote I added to my previous reply... :oops:

I think I'll mark this as solved now, as it's obviously my own fault in not using the tools Rainmeter offers, including the nested syntax (which I extensively used in the case of naming the variables and only "by accident" when it came to the variables values, and that only because nothing else worked, so I used it without really understanding the ins and outs of it).

Sorry for pointlessly bothering you with this. :confused:
jsmorley wrote: August 22nd, 2020, 5:34 pmIt's not really about nesting any "values", it's always about nesting the "names". The point is if the "value" of one thing is the "name" of another, that can certainly create a nesting condition.
Yep, I was referring to this when talking about names vs values:

Code: Select all

Text=[#MyVar[#MyOtherVar]]
Text=[#MyVar[&MyMeasure]]
Text=[&MyMeasure[#MyVar]]
Text=[&MyMeasure[&MyOtherMeasure]]
Last edited by Yincognito on August 22nd, 2020, 5:49 pm, edited 1 time in total.
Profiles: Rainmeter ProfileDeviantArt ProfileSuites: MYiniMeterSkins: Earth
User avatar
jsmorley
Developer
Posts: 22628
Joined: April 19th, 2009, 11:02 pm
Location: Fort Hunt, Virginia, USA

Re: [FEATURE REQUEST - Important] !UpdateVariables bang

Post by jsmorley »

Yincognito wrote: August 22nd, 2020, 5:44 pm Yep, it's all clear now - my bad. I guess I should have paid a bit more attention to what was alluded to between the lines in the quote I added to my previous reply... :oops:

I think I'll mark this as solved now, as it's obviously my own fault in not using the tools Rainmeter offers, including the nested syntax (which I extensively used in the case of naming the variables and only "by accident" when it came to the variables values, and that only because nothing else worked, so I used it without really understanding the ins and outs of it).

Sorry for pointlessly bothering you with this. :confused:
These kinds of discussions are almost never pointless...
User avatar
Yincognito
Rainmeter Sage
Posts: 7029
Joined: February 27th, 2015, 2:38 pm
Location: Terra Yincognita

Re: [FEATURE REQUEST - Important] !UpdateVariables bang

Post by Yincognito »

jsmorley wrote: August 22nd, 2020, 5:47 pm These kinds of discussions are almost never pointless...
True. Thanks for taking the time to explain it then. :thumbup:
Profiles: Rainmeter ProfileDeviantArt ProfileSuites: MYiniMeterSkins: Earth
User avatar
Yincognito
Rainmeter Sage
Posts: 7029
Joined: February 27th, 2015, 2:38 pm
Location: Terra Yincognita

Re: [FEATURE REQUEST - Important] !UpdateVariables bang

Post by Yincognito »

jsmorley wrote: August 22nd, 2020, 5:47 pm These kinds of discussions are almost never pointless...
Well, it appears the discussion is getting longer (or shorter, from a technical point of view, you'll see what I mean), because the following code - and yes, I need to set things this way in my actual skin, although I might be able to find a workaround - is producing a bunch of errors if the nested section variable is the empty string (or a measure, in this case, that is assigned the empty string to):

Code: Select all

[Variables]
String1=[&MeasureToggler]"
String2=[&MeasureToggler][&MeasureToggler]\\"
;String1="string"
;String2="A [#String1] is made out of characters"
String3="[#String1] and it has a length."
String4="[#String2] Period."

[Rainmeter]
Update=1000
DynamicWindowSize=1
AccurateText=1
BackgroundMode=2
SolidColor=47,47,47,255

---Measures---

[MeasureToggler]
Measure=Calc
Formula=(1-MeasureToggler)
UpdateDivider=-1
RegExpSubstitute=1
Substitute="^0$":"","^1$":"\\"
DynamicVariables=1

---Meters---

[MeterTest]
Meter=STRING
X=0
Y=0
FontFace=Consolas
FontColor=255,255,255,255
SolidColor=47,47,47,255
Padding=5,5,5,5
FontSize=16
AntiAlias=1
Text="String1 Format = either 'string' or 'text' (click based, dynamic)#CRLF#String2 Format = 'A [#*String1*] is made out of characters'#CRLF#String3 Format = '[#*String2*] and it has a length.'#CRLF##CRLF#String1 = #String1##CRLF#String2 = #String2##CRLF#String3 = #String3##CRLF#String4 = #String4#"
LeftMouseUpAction=[!UpdateMeasure *][!SetVariable String1 "[MeasureToggler]"][!SetVariable String2 "A [#String1] is made out of characters"][!SetVariable String3 "[#String2] and it has a length."][!UpdateMeter *][!Redraw]
DynamicVariables=1
Nested Empty String Variable Errors.jpg
By the way, don't be fooled by the screenshot, this happens because of the empty string, not the \\ string.

So, what is the solution to this yet another problem? Don't tell I can't use the empty string - I mean, it's a valid string like any other.
The funny thing is that the code works, both here in this simple sample, and in my actual weather skin - it's just that it's party time in the Rainmeter Log for errors... :???:

P.S. I only posted about this now because given that the code worked in my weather skin, I didn't look at the log to see the errors. A TON of them.
You do not have the required permissions to view the files attached to this post.
Profiles: Rainmeter ProfileDeviantArt ProfileSuites: MYiniMeterSkins: Earth
User avatar
eclectic-tech
Rainmeter Sage
Posts: 5384
Joined: April 12th, 2012, 9:40 pm
Location: Cedar Point, Ohio, USA

Re: [FEATURE REQUEST - Important] !UpdateVariables bang

Post by eclectic-tech »

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.
User avatar
Yincognito
Rainmeter Sage
Posts: 7029
Joined: February 27th, 2015, 2:38 pm
Location: Terra Yincognita

Re: [FEATURE REQUEST - Important] !UpdateVariables bang

Post by Yincognito »

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? :confused:

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... :???:
Profiles: Rainmeter ProfileDeviantArt ProfileSuites: MYiniMeterSkins: Earth