If you change an object, which has passed as an argument, then the changes takes effect outside the workflow, even if the argument is only an in-argument. This does not happen with basic types like string, int, etc.This is not what gonna happen. Or maybe I got something terribly wrong…
It doesn’t matter which studio version (enterprise/community).
I’m not sure if this is a bug or not, but certain datatypes do this on the backend because they’re passed by reference even if you don’t explicitly want to change the object outside of the workflow.
I do agree that it’s not intuitive without knowing how the objects are handled in C# generally, but a rule of thumb for now is that datatypes that can get big can change even if they’re only passed as In arguments.
This is just how object works… there is nothing wrong with it… just because you use it as an IN argument doesnt mean it should be read only… if you want to make this happen for you, when you receive an IN object, make a clone of it so you can change it in your sub workflow and the outer one will remain unchanged…
that makes no sense to me. UiPath decided to make arguments explicit as an in, out or i/o argument. What is the argument for that? “Because object wok like that” can’t seriously be the one. If so, then UiPath should follow that consistently. Either all variables are safe and keep the in/out rules or not and give up argument directions. Thats consistent and understandable for business users, developers, just everyone.
As I remember, if you write code in whatever-oo-language, you can decide byRef or byVal. I cannot remember that I ever had to live with a byRef for this and a byVal for that, because Microsoft said so or Oracle said so…
@Enrico Since UiPath works on a .Net Framework, I guess it brings out it’s features too. So the variables which are not a Value type are taken as references and also changes being made to it’s references are also being modified in the original parameter passed. You can take a look at this link
Also there are several workarounds for that, if you are passing a list as an argument, then use yourListVar.ToList to pass a copy of it and not the original reference, this Should allow it to preserve the original value.
Maybe I can’t see but what’s the point? Do you mean the first post about handling objects?
There’s is nothing wrong with that. It looks stange but its ok. ‘Point’ is a ‘struct’ and Pen is an object. Structs are not really an object. And it does not explain the different handling of variable types. C# does differ basic types and objects. Even in methods/functions. Or not?
It is not a bug and I think the topic should be renamed but the feedback is legit.
I’d expect a programmer to understand, scopes, mutable/immutable, value/reference/pointer even if none of his languages expose these notions. Well, there is no 100%.
Is it consistent with UiPath’s product? I don’t think this kind of awareness is expected in UiPath Studio consumption realm. I don’t think the result is consistent with the product’s intent.
While it is not a proper request for change it is already a valuable feedback.
A compromise might be to expose an option to force “by value”: that will raise the awareness without cluttering the interface and will allow a quick way to manage the issue (and yes I do know we can do the latter by passing the value or using a clone inside the workflow).
I agree, it is important to know how things work, just stating that this is not an UiPath thing, it is how .NET works, if you pass an object along, it will be a reference to the original one, so changes to it will be reflected as well…