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:
Create an array of Tuples as variable, e.g. “System.Tuple<System.String, System.String>”
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.
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.
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?
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.
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.
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.