ForEach in version 23.4.2 doesn't have sufficient options anymore

[niki.rmoutil]

Hello everyone,

the ForEach activity (UiPath.System.Activities version 23.4.2) no longer has any options in the Properties Panel.

You can see what I mean in the following 2 screenshots. The first one is version 23.4.2 with no options:

The second one below, is the same ForEach activity, but from version 22.10.5:

To be sure that this is not a bug I installed UiPath Studio Community Edition on multiple PCs, but it is the same everywhere.

Can somebody tell me what the design choice is behind this change?

I can’t think of a good reason to hide these options from the user, because now I’m absolutely dependent on Studio to infer the type correctly, which it seems it can’t do in more “complex” scenarios other than plain old String arrays.

To give an example:

1. Create an array of Tuples as variable, e.g. “System.Tuple<System.String, System.String>”
2. Create a ForEach activity and set the array of Tuples as “List of items”

UiPath will infer the Items as System.Object, which doesn’t make any sense in this case, and if you want to use the Tuple normally, like currentItem.Item1 or currentItem.Item2, you need to cast it beforehand.

[loginerror (Maciej Kuźmicz)]

Hi @niki.rmoutil

I’ve tried it just now and it seems to work just fine (latest Studio Community 2023.4)

The desired outcome of this simplification would be to make things easier to use. We are pretty confident we can make it properly interpret the object type, and this is why opted to develop this activity in this direction.

Would you mind sharing a zip of a sample project where this is not working correctly for you? Also, please let us know the Studio version you were using above.

[niki.rmoutil]

Hi @loginerror

First and foremost, thank you for taking time to answer my question

I just got a new laptop, so the studio version is the same as yours (Community 2023.4)
And here is a sample project I created:
TestProject.zip (141.4 KB)

If I do the same as you did in your screenshot, I get errors and no Intellisense for the Tuple Items

I also checked the .xaml file and it is indeed listed as a object:

<ui:ForEach x:TypeArguments="x:Object" CurrentIndex="{x:Null}" DisplayName="For Each" sap:VirtualizedContainerService.HintSize="410.4,370.4" sap2010:WorkflowViewState.IdRef="ForEach`1_1">
      <ui:ForEach.Body>
        <ActivityAction x:TypeArguments="x:Object">
          <ActivityAction.Argument>
            <DelegateInArgument x:TypeArguments="x:Object" Name="currentTuple" />

Though, at runtime it is correctly interfered as Tuple<string,string> (tried it with currentTuple.GetType()), but that isn’t any helpful if UiPath doesn’t let me execute the code because of the above mentioned and seen error.

I would also like to add that I don’t want to offend anybody, and I believe you when you say you are pretty confident to infer every type properly.
But errors are inevitable, and in cases where it is not easily possible, or UiPath makes an error, there is currently no way to change that, except to lower the package version or change it directly in the .xaml file, and I don’t think either of these is an adequate solution for that.

To my knowledge, earlier versions of this package/this function also inferred the type automatically, but I could still set the type manually if I wanted.
I’m also all for simplificationd, but what I don’t understand is why these options are completely omitted?

[loginerror (Maciej Kuźmicz)]

Thank you for test project. I tested it on my own end and found the most likely reason by comparing project.json of your test project and my own → the difference was in C# vs VB.net. It looks like it doesn’t detect it properly on C# projects and I filed a bug for that.

@niki.rmoutil

I would also like to add that I don’t want to offend anybody, and I believe you when you say you are pretty confident to infer every type properly.
But errors are inevitable, and in cases where it is not easily possible, or UiPath makes an error, there is currently no way to change that, except to lower the package version or change it directly in the .xaml file, and I don’t think either of these is an adequate solution for that.

To my knowledge, earlier versions of this package/this function also inferred the type automatically, but I could still set the type manually if I wanted.
I’m also all for simplificationd, but what I don’t understand is why these options are completely omitted?

I will take it as valuable feedback. We are often bold in our design choices based on multiple reasons and with the goal to make the experience smoother and less frictionless, but we will not be deaf to the voice of our users if we hear that we should bring it back.

[Jon_Smith]

@loginerror

but we will not be deaf to the voice of our users if we hear that we should bring it back.

Please bring it back. I feel you are aiming to make things too simple.
This is fine for StudioX but in normal Studio allow us to override the data type that has been inferred. I have previously had many issues with it trying to guess the type and it reverting to an object and me needing to switch it back, but at least I could indeed switch it back.

You aren’t hurting anything by giving us a choice, its simple for users that don’t care, they simply won’t notice it, for advanced scenarios or where the inference doesn’t work, we can still correct it.

As any good developer I like the code I use to be flexible but also not make choices for me that are sometimes incorrect, let me make that choice instead.

[niki.rmoutil]

I’m completely with @Jon_Smith.

For StudioX it is plausible, but for Studio I would want to have the possibility to tinker as much as I can on activities.

[loginerror (Maciej Kuźmicz)]

Just to close this topic as well. This was fixed in the meantime as part of the new System package release.