Problems With Accessing Indexed Values Of Attrubutes

[Darius1968]

I'm trying to troubleshoot unexpected behavior I'm getting in setting up a data driven category that enumerates as one of its levels the contents of an attribute. 

I've attached a screenshot (shown below) that conducts eight different tests on my attribute {File.AT.TV/Movie-Genres.Genres}. 


So far, I've been able to prove (#s 6,8,9) that, for this file, this attribute has two values:  #6 shows that there are two values. #8 shows the 1st value, and #9 shows the 2nd value. 

However, despite my proving there are two values, the other tests (namely, #5) indicate only one value:  Take note of #5 invoking the foreach: function with the {value} argument.  Here, I'm trying to enumerate each of the two values, wrapped in [].  Instead of each value being enumerated separately, as expected, the output is a one value, with ; separating the two values.  This is contrary to what the IMatch Help says would happen. 

[Mario]

Shall this be moved into bug reports?
Sounds like a bug report, not like a general discussion topic.
If you consider something to be a bug, please always open a bug report.

Accessing multi-value Attributes in a variable using foreach is probably something one one user has ever done.
Not an issue that will affect many users, else we would have heard about it. Maybe this is by design, I don't recall.

Made a quick check and it seems to work just fine.
File with 3 entries for the Attribute "Title".

Attribute Values:
Title 1
Title 2
Title 3

Variable: {File.AT.Notes.Title}
Result: Title 3;Title 1;Title 2

Variable: {File.AT.Notes.Title|foreach:<{value}>}
Result: <Title 3><Title 1><Title 2>

Correct. No problem.

[David_H]

(namely, #5) indicate only one value:  Take note of #5 invoking the foreach: function with the {value} argument.  Here, I'm trying to enumerate each of the two values, wrapped in []. 

You have additional brackets in #5.

|foreach:[{value}]

Mario has :

|foreach:{value}

I'd guess this will evaluate [{value}] instead of {value} x3

[Mario]

{File.AT.Notes.Title|foreach:[{value}]} returns [Title 3][Title 1][Title 2] in my test. Which is the expected result.

[Darius1968]

I don't even have {File.AT.Notes.Title} in my database!  However, I created a new test database with it's own {File.AT.Notes.Genre} attribute.  And, for {File.AT.Notes.Genre|foreach:<{value}>}, I'm still getting as my result, <FANTASY;HORROR>. 

So, do you still get the (correct) result if you create a whole new attribute?  I ask because since I'm not getting the correct result, I'm now trying to use process of elimination to try and troubleshoot. 

[Mario]

I don't even have {File.AT.Notes.Title} in my database!

That's just what I used in my test. The name of the set or Attribute is irrelevant.
Next try, new set, also successful. See attachment below.

[Darius1968]

This is the strangest thing!  This latest screenshot shows once again that I have success in referencing each individual value with the index: function, but I get unexpected outcome with the foreach: function! 


This is not a problem with the database itself as I'm running into the same problem with a different newly created database as well. 

Could it be a setting within IMatch itself that is causing this?  Where should I go in troubleshooting from here? 

[Mario]

No idea.
Does it work without the [] ?

[sinus]

I tried this here:

{File.AT.Verrechnung.Kunde|foreach:[{value}]}
{File.AT.Verrechnung.Kunde|foreach:{value},}
{File.AT.Verrechnung.Kunde|foreach:{value}}

I get in VarToy:
[Enderli][Richards][Voney]
Enderli,Richards,Voney,
EnderliRichardsVoney

what looks correct for me.

[Darius1968]

Nope.  Does not work without the [].  And, I tried just what Markus did, without success. 

[Darius1968]

Could it have anything to do with a Windows setting or anything 3rd-party? 
I'm wondering why the index function works, but the foreach function doesn't? 

[sinus]

Could it have anything to do with a Windows setting or anything 3rd-party? 

I am really not a IT-expert.
But nothing does wonder me anymore, your idea of a windows setting seems to me very good possible.

I installed Cura 5.1, a 3D - slicing program.
All worked well, 3 days.
After this suddenly the preview was VERY slow (instead 0.1 sec new 10 sec). All works well except the slowness.
I found nothing on the internet, installed the newest graphic cards, nothing, restarted, and so on.
Nothing helped.

What it could be: I changed something in the mouse-preferences from windows. I changed it back and cura worked again for 30 seconds, then again not.
And so on ....

This is only one mystery of my computer-experience: sometimes it is simply not to explain.
I have often read here in this forum, exactly the same thing worked for all users, except one or two users had problems.
Of course not always, but quite often enough, at least it was a windows or 3rd-party-problem, like you wrote.

Maybe thousends of drivers, preferences has to interact and maybe, sometimes, 1 in 100'000 cases goes wrong.

I have simply not clue for your problem, as I have written, here this works.

[thrinn]

I can also only confirm that it works for me. I assume that you are also on IMatch 2021.16.4?
I tried it with a simple text attribute, also with a reference attribute. In both cases, everything works as expected. So, still no clue...

Code Select Expand


1 {File.AT.Notes.Genre|foreach:[{value}]}
2 {File.AT.Notes.Genre}
3 {File.AT.Notes.GenreRef|foreach:[{value}]}
4 {File.AT.Notes.GenreRef}

gives

Code Select Expand

1 [Fantasy][Horror]
2 Fantasy;Horror
3 [FANTASY][HORROR]
4 FANTASY;HORROR

[Darius1968]

Yes, I am on the latest version of IMatch.  Could Windows 11 have a hand in the problem?  Anyone here having success on Windows 11? 

[thrinn]

I am still on Windows 10, so I can not comment on this question. But I am pretty sure that Mario tested it on Windows 11.

[Mario]

I test on Windows 11.

[Darius1968]

Is this statement valid? 
{File.AT.Notes.Genre|index:0;index:1}

...Or, is only one index statement allowed per variable expression? 

[Mario]

Is this statement valid? 
{File.AT.Notes.Genre|index:0;index:1}
...Or, is only one index statement allowed per variable expression?

This syntax is invalid not from the help page.
You cannot append indices using a semicolon or whatever.
If you want data from multiple indices, use multiple variables:

{File.AT.Notes.Title|index:0}{File.AT.Notes.Title|index:1}

[Darius1968]

Okay, didn't think it was.  Just checking to be sure.  Still, trying to figure out what the real problem is, however. 

[sinus]

Yes, I am on the latest version of IMatch.  Could Windows 11 have a hand in the problem?  Anyone here having success on Windows 11?

My correct results (from my post above) are created with the newest IMatch-Version and Win 11.

[Darius1968]

Could this possibly be JavaScript related?  If so, anything I can do to be sure that everything is right in Windows and/or IMatch to ensure its correct functioning? 

[Mario]

This has nothing to do with JavaScript.
The VarParser parses the specified variable internally, and returns the result as a string (text).
This is what the VarParser then displays as the result.

Make sure the Attribute you are working with contains the contents you think it contains.
Plays with the variable syntax, avoid any special characters in your Set and Attribute names.
Using / in a Set or Attribute Name is already quite extra, and while this should work in the Attribute Panel and elsewhere, it may fall on your feet when you use it in Variables or Apps.
Best to keep names simple and easy, for folders, files, categories and Attributes.

That being said, I created an Attribute Set following your naming convention yesterday, and it worked just fine.
This seems to be something that only occurs on your PC. And even with multiple databases, which is even more obscure.
None of the other users or myself could reproduce this effect, so I'm not having any further idea right now.
I'll keep this in mind and when I come up with another idea, I'll let you know.

[Darius1968]

At this point, since this problem is across multiple databases, I'm thinking to simply reinstall IMatch anew - Reinstall after a complete 'wipe-clean' of IMatch from Windows.  Is the procedure outlined here still completely valid today? 

[Mario]

This should not make any difference and will only generate a lot of work for you, without positive outcome.
Since no other user could reproduce this and it fails across multipel databases only for you, it can only be the variable you use, or the Attribute values. Not something caused by the IMatch installation.

[Darius1968]

Well, as has been said earlier in this post, I have a tiny database (10 MB, 6 files) that - on my end, at least - demonstrates the incorrect functioning of the foreach: function.  I can gladly make it available to you, if you think it could possibly reveal anything not correct.  (I think everything is fine because the one and only attribute in that database is demonstrating its dislike of the foreach: function)

Let me know if you think it's worthwhile for me to make it available.  If so, you can let me know what files you need...Thanks! 

[Darius1968]

Since no other user could reproduce this and it fails across multipel databases only for you, it can only be the variable you use, or the Attribute values. Not something caused by the IMatch installation.

Well, I can confirm it's not anything about the attributes because I now see that I'm running into the same problem with trying to involve foreach: with keywords.  (Screenshot below shows a file with three keywords - Gun, Trees, Leaves)


Since, the index: function works fine - Able to tell the difference between "Gun" and "Leaves", with index:0 and index:2, respectively, I suspect something is amiss with how foreach: is working on my system.  What exactly is involved in IMatch working with that function:  Is it built-in, 3rd-Party, or is it something which IMatch calls upon Windows 10/11, and hence something I have to check in Windows itself? 

[Tveloso]

On my PC, I was getting the same results as Darius.

Given a file for which this variable:

      {File.MD.XMP::dc\subject\Subject\0}

...returned the following result:

      rocks;Water;waterfall;Plant;tree

...this set of variables:

      {File.MD.XMP::dc\subject\Subject\0|index:0}
      {File.MD.XMP::dc\subject\Subject\0|index:1}
      {File.MD.XMP::dc\subject\Subject\0|index:2}
      {File.MD.XMP::dc\subject\Subject\0|index:3}
      {File.MD.XMP::dc\subject\Subject\0|index:4}

...returned this (which is as expected):

      rocks
      Water
      waterfall
      Plant
      tree

But this variable:

      {File.MD.XMP::dc\subject\Subject\0|foreach:--{value}--  }

...returned this result (which is unexpected):

      --rocks;Water;waterfall;Plant;tree-- 

I had a vague recollection of reading about another issue some time ago, related to the list separator configured in Windows, so I checked my setting, and found that it was set to a comma on my PC:

       

When I changed it to a semicolon:

       

...(and restarted IMatch), now the foreach variable returned the expected result:

      --rocks--  --Water--  --waterfall--  --Plant--  --tree-- 

...but {File.MD.XMP::dc\subject\Subject\0} continued returning a semicolon-separated list.

So it seems that IMatch uses the semicolon internally for repeatable tags, but when processing foreach, it interrogates the Windows Region settings, and if the list separator there is not the semicolon, then foreach does not "recognize" the tag as containing repeatable values?...

Interestingly, just as IMatch consistently used a semicolon-separated list for the value of that tag, the ECP consistently used a comma-separated list for it (regardless of the List Separator setting in Windows).

[Darius1968]

Tony-
Thanks so much for your input and your insights...  When I change the list separator, it works!  Very helpful and very much appreciated! 

[Mario]

Very good work!
Something that finally helps me to figure out why Darius has this problem.

foreach and many other splitting/parsing/tokeinzing functions use the default list separator as configured for the current user in Windows.
This helps to deal with problems caused by parsing numeric values containing decimal commas and thousand separators. It is unwise to use the , both as a thousands separator and list separator, for example.
Repeatable tags use the list separator configured for the IMatch engine, which is available as "Keyword Separator" under Edit > Preferences > Metadata.

@Darious: I suggest to add a replace , with ; before you apply foreach on your system. This should do just fine.

I shall add a remark to the foreach documentation for a future IMatch version.

[Darius1968]

It's "Darius", not "Darious"...  Thanks for the tip. 

[Darius1968]

When I set the list separator back to ,, and use this statement:
{File.AT.TV/Movie-Genres.Genres|replace:~,==~;;foreach:[{File.AT.TV/Movie-Genres.Genres}]}
...It doesn't work.

Is my syntax correct? 

[Mario]

Don't escape the comma with ~, just use , ?

I have corrected the typo in your name in my post. Sorry. Working mobile, small keyboard, robot fingers...

[Darius1968]

I have corrected the typo in your name in my post. Sorry. Working mobile, small keyboard, robot fingers...

No worries!  Just pointing out the typo 

Don't escape the comma with ~, just use , ?

{File.AT.TV/Movie-Genres.Genres|replace:,==~;;foreach:[{File.AT.TV/Movie-Genres.Genres}]}
...doesn't work either. 

P.S.

And, this:
{File.AT.TV/Movie-Genres.Genres|replace:~;==,;foreach:[{File.AT.TV/Movie-Genres.Genres}-rem.{remaining}]}

...gives me this:
[THRILLER;ACTION;DRAMA-rem.2][THRILLER;ACTION;DRAMA-rem.1][THRILLER;ACTION;DRAMA-rem.0] .

[Mario]

What does {File.AT.TV/Movie-Genres.Genres|replace:,==~;} produce?

...doesn't work either. 

Meaning unclear. What is the output? What is the input?

...gives me this:

Maybe not everything can be done with variables.
I did not try to produce a perfect solution for every fringe workflow or use-case.
Maybe enter your Attributes in the way you later need them and don't waste so much time trying to figure out very complex variables.

[Darius1968]

Sorry, totally my bad!!!

This:
{File.AT.TV/Movie-Genres.Genres|replace:~;==,;foreach:[{File.AT.TV/Movie-Genres.Genres}-rem.{remaining}]}
...is totally wrong, and not valid, because the valid options for foreach: are - {value}, {remaining}, and {index}

So, I replaced with this expression: 
{File.AT.TV/Movie-Genres.Genres|replace:~;==,;foreach:[{value}-rem.{remaining}] }
...and I get this result:
[THRILLER-rem.2] [ACTION-rem.1] [DRAMA-rem.0]

Conclusion:
All is well, using the comma as the list separator in the presence of replace:~;==, .

[Mario]

Very well.

[PandDLong]

I just ran into this same problem that Darius had.   It was driving me crazy - I copied the example from the Help page and even it didn't work as documented.  

Prior to posting a bug report - searched the forum and ...   I have the solution in hand.  IMO - the Windows 11 upgrade reverted to the , list separator as I did not have this problem previously before my upgrade - but maybe my memory is bad.

All is well that ends well.  Thanks to the solution being found and posted previously.

[Mario]

I don't follow, sorry.
You copied which example from the help?
I don't see why the list separator set in Windows has any influence on variables?
Variables use , to separate function parameters and ; to separate functions (and | for the first function). This is hard-coded.
Maybe when you show me the variable you have used I understand better.

Do you refer to this (from the IMatch help on foreach):

forEach splits values by looking for the list separator character configured for the current user in the Windows control panel.
If this character differs from the default separator character IMatch uses for repeatable tags like keywords (configured under Edit > Preferences > Metadata), you may need to put a replace in front of the foreach to e.g. replace ; with , if needed.

[PandDLong]

Mario,

I was trying to get the foreach function to work without success. So, I copied the following from the help page:

{File.MD.hierarchicalkeywords|foreach:[{value}]}

and I populated an image with simple keywords  one;two;three;four   and VarToy gave the following as the result.

   [one;two;three;four]

Then I knew my problem wasn't my efforts but something else as not even the example worked properly.  I found this thread - followed Tveloso's suggestion and discovered my Windows list separator was a , and when I switched to ; all worked ok.

Am I making sense now?

Michael

[Mario]

This is why the help explicitly mentioned the list separator character and how the user might need to switch it, according to the Windows settings active for the current culture.

[PandDLong]

Fair point.  It was working for me previously so I didn't think that was the problem - my Windows upgrade (or some other action) reverted it back.

In any case, it was helpful to find this thread.

All is well that ends well.

[PandDLong]

I should add that everything else I was doing with lists worked fine - entering or editing them in a metadata panel, creating or adding to them in a metadata template and the index and count functions so it seemed that lists were "ok" and thus my separator setting was okay.     It appears to just be select cases where the Windows setting over-rules the iMatch setting for the list separator.  

I add the above just for additional clarification.   As I said - all is well that ends well.