Search and match words in external file

[rbriddickk84]

Greetings!

I have trouble understanding the mechanics of external variables (in external .inc file).

So i have an external .inc file with four digit named variables, like "0911" <- this is a combination of month numbers (09) and day numbers (11).
Every variable has words as values.
Like:

.inc file

Code: Select all

[Variables]
0000=nothing
.
.
.
0911=something

Now i tried to access that 0911 variable with a String measure dynamically. So i set a temporary variable as "0911":

.ini file

Code: Select all

[Variables]
TempVar=#0000#

[MeasureMonth]
Measure=Time
Format=%m
OnUpdateAction=[!UpdateMeasure MeasureDay]
DynamicVariables=1
UpdateDivider=-1

[MeasureDay]
Measure=Time
Format=%d
OnUpdateAction=[!SetVariable TempVar "[$MeasureMonth[$MeasureDay]]"]
DynamicVariables=1
UpdateDivider=-1

[StringMeasure]
Measure=String
String=#TempVar#
IfMatch=something
IfMatchAction=[!Log "got one"]
DynamicVariables=1
UpdateDivider=-1

Now i only got the numbers, but cannot get the actual word from the external file. This code i included a recreation of my complex script, just a fragment, but the base is there. I tried to change the variable for "IfMatch" mode to count the days like [$MeasureMonth[$Counter]], because i want to check if the current month matches with a certain word.

But the #TempVar# keeps returning only with the four numbers.

Also have tried this: [!SetVariable TempVar "#[$MeasureMonth[$MeasureDay]]#"] to make the variable #0911#, but the String measure is like "#0911#, but not grabbing the word from the ext file.

Thanks for the helps in advance!!

[eclectic-tech]

Try: OnUpdateAction=[!SetVariable TempVar "[#[&MeasureMonth][&MeasureDay]]"]

This uses the nested variable syntax along with the normal measure syntax and works here.

...Files I used...

Items.inc

Code: Select all

[Variables]
0000=nothing
0911=something

Search.ini

Code: Select all

[Variables]
@include=#Currentpath#items.inc
TempVar=

[MeasureMonth]
Measure=Time
Format=%m
OnUpdateAction=[!UpdateMeasure MeasureDay]
DynamicVariables=1
UpdateDivider=-1

[MeasureDay]
Measure=Time
Format=%d
OnUpdateAction=[!SetVariable TempVar "[#[&MeasureMonth][&MeasureDay]]"]
DynamicVariables=1
UpdateDivider=-1

[StringMeasure]
Measure=String
String=#TempVar#
IfMatch=something
IfMatchAction=[!Log "got one"]
DynamicVariables=1
UpdateDivider=-1

[Search]
Meter=String
FontColor=255,255,255
Text=#TempVar#
DynamicVariables=1

[rbriddickk84]

Try: OnUpdateAction=[!SetVariable TempVar "[#[&MeasureMonth][&MeasureDay]]"]

This is incredible! It worked! I could swear i tried that one as well!

Everything works now, thank you very very much! So weird!

[eclectic-tech]

Happy to help!

That is strange, since you had DynamicVariables=1 set on the measure.

Nested variables are resolved when the bang is executed, but that shouldn't have made any difference versus using
#[&MeasureMonth][&MeasureDay]#
They both should have resolved to "something"!?

The answer is above my pay grade! Glad it is working for you.

[rbriddickk84]

Happy to help!

That is strange, since you had DynamicVariables=1 set on the measure.

Nested variables are resolved when the bang is executed, but that shouldn't have made any difference versus using
#[&MeasureMonth][&MeasureDay]#
They both should have resolved to "something"!?

The answer is above my pay grade! Glad it is working for you.

Amazing and strange too. Honestly i tried every combinations what came to mind. I have no idea, sometimes it is like when you try plug in a USB in a slot. First u try correctly, but it won't go, u turn it, obviously the won't work, then 3rd time flip back to original position and it works.

Thank you again your kind help!

[Yincognito]

Happy to help!

That is strange, since you had DynamicVariables=1 set on the measure.

Nested variables are resolved when the bang is executed, but that shouldn't have made any difference versus using
#[&MeasureMonth][&MeasureDay]#
They both should have resolved to "something"!?

The answer is above my pay grade! Glad it is working for you.

If the standard variable syntax worked the way you mentioned, there wouldn't be a need for the nested variable syntax. It was just another nesting level required here, nothing strange about it, IMHO.

[eclectic-tech]

If the standard variable syntax worked the way you mentioned, there wouldn't be a need for the nested variable syntax. It was just another nesting level required here, nothing strange about it, IMHO.

The standard syntax returns a variable syntax correctly as #0911#, which is expected.

When you use that value in a STRING MEASURE, #TempVar# is not resolved to the variable's value of 'something'. Instead, it is treated as plain text #0911# and the IfMatch test fails.

By using nested syntax in the !SetVariable bang, it is resolved in the bang and #TempVar# is set to the variables value of 'something' instead of #0911# and the IfMatch test can be used on it.

The issue was the string measure does not resolve the variable to its value, it is treated as plain text.

Not strange, just unexpected until you think about how the string measure works.

[Yincognito]

The standard syntax returns a variable syntax correctly as #0911#, which is expected.

When you use that value in a STRING MEASURE, #TempVar# is not resolved to the variable's value of 'something'. Instead, it is treated as plain text #0911# and the IfMatch test fails.

By using nested syntax in the !SetVariable bang, it is resolved in the bang and #TempVar# is set to the variables value of 'something' instead of #0911# and the IfMatch test can be used on it.

The issue was the string measure does not resolve the variable to its value, it is treated as plain text.

Not strange, just unexpected until you think about how the string measure works.

But it IS plain text, isn't it? I mean, why not, since # are perfectly valid characters on their own, which you can see if defining a variable to #blahblah# assuming there is no blahblah variable defined elsewhere - it will be interpreted as string without issues. Also, the said variable was made of entirely separate string parts, i.e. #, 09, 11 and #, which needed to be parsed as a variable reference as a whole, hence the extra nesting level. So, with the risk of disappointing you, I don't find that unexpected either.

[eclectic-tech]

You ask why standard variable syntax wouldn't work in the !SetVariable bang...

Because when you try to use that variable in a string measure it does not use a variable's value, as I said, and you repeated, it evaluates whatever text is in the string.

So, that is why the nested syntax is needed in the !SetVariable bang.

The bottom line is variables are not resolved in string measures, which may not be apparent to everyone...

[Yincognito]

You ask why standard variable syntax wouldn't work in the !SetVariable bang...

Those wre just rhetorical questions to emphasize the point. I fully agree that the nested syntax is needed here. I only argued about whether that need is strange or unexpected, which I believe it's not, that's all.

The bottom line is variables are not resolved in string measures, which may not be apparent to everyone...

The #[&SomeMeasure][&OtherMeasure]# form is not, since it's nothing to resolve here bar the measure values. The [#[&SomeMeasure][&OtherMeasure]] is though, since a variable is actually referenced here via the last nesting level aka [#...], which is required in this case.

I have a feeling that somewhere along these lines there's a slight misunderstanding of what each of us is stating, lol...