Feature or a Bug?

Help
1

Hey all!

Came across something and I am not sure if it is a feature in .NET or just a UiPath bug. Say I create a data table or a dictionary in my main workflow and pass it to a sub workflow. If I pass either of those variable types in as an “in” argument, I can still write to them and the changes will be reflected in my main workflow.

Can someone help illuminate this for me?

Like always, thanks for any time you give this post!

-James Mills

1 Like
2

This is a bug. Though some programming languages work this way, this is unintended behavior for UiPath Studio.

3

@Anthony_Humphries

In RE Framework, transactionItem is passed to process as in_TransactionItem and not as io_TransactionItem. When working with DataTable/DataRow TransactionDate/TransactionItem it is convenient to update the transactionData by udpating in Process the in_TransactionItem. While the in/out/io argument passing direction might suggest some protection, I had to test if I needed to change again the framework to work with datatables: when updating in Process the in_TransactionItem, you change is reflected into the “global” TransactionData.

From that, I came to expect that arguments are passed by reference and that the reference might change into the invoked workflow’ scope for an immutable object type when changing the value but for a mutable object, the reference still persist while related objects are changed.

I’d like to have some insight from UiPath.

4

@msan That’s something about the REFramework I hadn’t noticed! I still think think if the object is mutable, Studio should automatically create a copy when using an In argument for mutable objects. Especially if the goal is to make creating automations in Studio more accessible to people without programming backgrounds.

2 Likes
5

@Anthony_Humphries

I’d like to see an Academy video about pointers :slight_smile: I agree with you that by reference vs value is difficult to grasp for beginners and that many UiPath users don’t even expect to dive in “coding considerations”.

At first glance, allowing to set Direction and Passing mechanism for arguments (with a default set to by value to keep it intuitive) might help to keep that notion quite explicit when looking for it and provide flexibility.

@jamesmills

If you pass a copy of these instances as argument, you should be safe. Does instanciate a local variable from the argument do the trick?

6

True. The reference feature is fine as long as it’s clear for beginners how it works. Possibly by providing a warning in the project analyser if a mutable object is passed as an In argument.

1 Like
7

Is there something special about the data types of dictionaries and Data tables vs String/int/bool? Since the latter does not change when passed through as an in argument

8

@jamesmills
As far as I know for VB, String, Int and Bool are immutable. It’s quite tricky to explain then I won’t risk to improvise an answser. Look at the wikipedia link below and feel free to ask about details.

EDIT: add a youtube link

9

It gets somewhat technical, but dictionaries in VB.Net are passed by reference, meaning that even if you pass the variable to a workflow, it will change if you change it. You have to explicitly make a copy if you don’t want to change the original. While I’m not sure what the original intention for separating the two was when immutable vs mutable objects were differentiated, I believe datatypes which can take a large amount of space were made mutable so a copy would not automatically be created when the object is passed, saving on memory.

10

Hi @jamesmills,
I’ve observed the same behavior not just with DataTables and Dictionaries, but also with Arrays and Lists. When these variable types are passed as “in” arguments to sub-workflows, any changes made within the sub-workflow are reflected in the main workflow. This might be a broader issue potentially related to the way UiPath’s ReFramework handles argument passing and variable references.

11

This isnt a bug, is a feature of VB and C#.
Its just how things works in programming languages. Objects like these are memory intensive, so instead of creating a copy everytime it’s send as an argument, the compiler will pass as a reference, where it will suffer any changes that may occurs on the function, or in our case, the workflow

12

Hi @lucas.stern, you have raised a valid point and I understand that the behavior of reference types being modified in sub-workflows is a feature of object-oriented programming. However, this raises a question: what is the point of having different argument directions like ‘in’, ‘out’ and ‘in/out’ if variables can be modified regardless of the direction set?

13

Its because the argument direction is a exclusive from UiPath.
In most cases (for the most commom datatypes), it will make sense, what we are discussing here is a exception from the rule.

Since UiPath is build on the .Net framework, it has to follow the same rules. Well, at least it should naturally follow the same rules. But there’s some decision that UiPath took that changed the behavior (I’m looking at you Try-Catch-Finally).

For our case of pass-by-ref, a warning would be welcome. The moment that UiPath decided to market her product as an “Automation Solution for those that dont know programming”, they should ensure that those programming caveats and exception are not something that will impact the development phase.