getfieldselections() returned a delimiter-separated list of the selected values from the specified field. It's per default limited to 6 or 12 values which could be overwritten with the third parameter. If the list should be not just displayed within a text-box or a title else be used as parameter or condition it requires a content-handling because any string-values would need a quoting which is possible to implement but increased the complexity.
In your example the selected values of Field2 are used to define the set analysis selection-state of Field3 or to say it other words to synchronize the selections between different fields. A quite common use-case is to have an extra island-table (not related to the normal data-model) maybe with a date-field which is then used to define a selection-scope without selecting the normal period-fields from a calendar (very often also implemented by variables with separate from-to dates). But of course there are various other scenarios possible.
Like mentioned p() and e() are easier and more powerful to use because they don't touch the field-values itself else the index-values behind them which means the type of content isn't important anymore. Further they are itself set analysis capable which means they could be nested and/or related to further selections states in various ways.
It's very rarely that the use of getfieldselections() is helpful. More flexible in many ways would be to use a concat(distinct Field) and within a set analysis just p() and e() to get the possible respectively excluded values without to consider the number of values or their data-interpretation.
getfieldselections() returned a delimiter-separated list of the selected values from the specified field. It's per default limited to 6 or 12 values which could be overwritten with the third parameter. If the list should be not just displayed within a text-box or a title else be used as parameter or condition it requires a content-handling because any string-values would need a quoting which is possible to implement but increased the complexity.
In your example the selected values of Field2 are used to define the set analysis selection-state of Field3 or to say it other words to synchronize the selections between different fields. A quite common use-case is to have an extra island-table (not related to the normal data-model) maybe with a date-field which is then used to define a selection-scope without selecting the normal period-fields from a calendar (very often also implemented by variables with separate from-to dates). But of course there are various other scenarios possible.
Like mentioned p() and e() are easier and more powerful to use because they don't touch the field-values itself else the index-values behind them which means the type of content isn't important anymore. Further they are itself set analysis capable which means they could be nested and/or related to further selections states in various ways.
