Missing the Type Argument property on the For Each activity

Feedback Activities
,
1

Since a recent UiPath Studio version, it was removed the type argument property from the For Each activity. I’m aware that the activity with the more simple data structure automatically set’s the argument type correctly, but the same doesn’t happen with more complex or unusual ones, and I find myself having to use DirectCast inside the activity to set the type of each object iterated. Is it possible to have the Type Argument property back?

1 Like
3

@mmcruzRPA Agree. but by downgrading package we can use previous one with Argument Property

4

True @raja.arslankhan , but I think it shouldn’t be removed from the most recent package versions and shouldn’t be needed to downgrade the package to have the property available on the activity.

2 Likes
5

@mmcruzRPA I voted to you. Let c

1 Like
6

When I first saw the change I absolutely agreed and hated it forcing the wrong data type (or going to Object).
It does seem that latter version have improved on this and even with complex data types or LINQ expressions it seems to be getting the correct data type to me now.

Do you have a specific one that still doesn’t work? (more for my own curiosity here).
I still agree it should be an option for edge cases where the wrong type is used.

7

Hi @mmcruzRPA

If that error occurs, We can able to access it when we remove the activity,Add it again and Pass the collection variable.

Hope it helps!!

8

There are some that doesn’t work at least on the most recent version. What I remember, at the moment, it’s iterate a JSON object where I have to access the tokens from the iterated item. Another that I remember it’s about iterate output from the Data Extraction Scope (on DU), where the type of each iterated item is UiPath.DocumentProcessing.ContractsResults.ResultsDataPoint.

9

Hi @pravallikapaluri , it isn’t an error, it’s just the For Each activity doesn’t recognize properly the argument type of List of items in some cases, and on those cases, I have to do a direct cast for each iterated item to have the correct type. With the Type Argument property, I wouldn’t have to do such thing.

10

@mmcruzRPA

One thing instead of using direct cast inside the loop…you can use cast in the for loop in argument properties itsef once …

Eg: Liststr.Cast(Of String)

And I do agree type argument will help in getting things easy with ui

Cheers

11

Hello @Anil_G , what’s needed is to do direct cast to the item from the list, that sometimes the activity doesn’t recognize what should be the item type correctly, and to cast it, the only way that I know at least it’s to cast on the start of the loop with assign activity. That wouldn’t be needed at all if the Argument Type property was there as before.

12

@mmcruzRPA

So the idea or internally what happens with type argument option is the same…that the given collection is casted as needed…instead of casting each individual items…I totally agree with you that type argument will make life easy by giving UI option

But as work around instead of casting at each iteration level…I amgiving you an option to cast at the list level only…so that the casting can be avoided in loop

Cheers

1 Like
13

Got it @Anil_G , thanks for clarifying, I tried what you suggest and it works! I still prefer the property back, but this is way better than using the assign per each iterated item for sure! Thank you :+1:t2:

1 Like
16

Thank you for the feedback @mmcruzRPA and everyone.

We are looking closely at the feedback after this change and we are considering softly reverting to the type picker property when the auto-detection fails (in which case it resolves to an Object).

As mentioned above, we already iterated on the auto detection based on previous bug reports, and we would appreciate any and all examples you might have of the auto detection not doing well to continue improving the feature to make it as robust as possible.

17

Or… ya know. Just giving us an option, maybe via a button or link on the activity itself to activate a manual selection.

Its better if you don’t take the control out of our hands. Auto populate is nice, even hide it if that works for your strategy for low code. But give us a way to still control it if we want rather than trying to logic to only do it in certain scenarios as you almost certainly won’t get 100% coverage.

20

Stay tuned for System 23.10 - the option is simply coming back.

4 Likes