I’ve today migrated a large project to remove Windows legacy support in Studio 2022.10.3.
The only problem is with an Invoke VBA activity, where I’m passing parameters of differing types. In this case, it has two strings, 1 integer and two strings:
This was fine before but now I get an error BC36915
"Compiler error(s) encountered processing expression “{strWorkSheet_Name, strFilterRange, intFilterColumnIndex, strFilterColumnValue}”.(2) : error BC36915: Cannot infer an element type because more than one type is possible. Specifying the type of the array might correct this error.
The expected type for the parameter property is an IEnumerable. The previous method of using an array { } of objects will no longer work, if there the objects are of more than one type.
I’m guessing that the solution may be to use a List (Of Objects) and append each object to the list as separate activities, but, even if this works, it’s quite an inefficient way of coding.
Help/alternatives/verification I am on the right track appreciated.
Yes, that was the first thing I did. Assigning mixture of object types to an array of objects Object results in the same error on the Assign statement.
Then may be you can pass everything as string and then convert inside you vba as you are looking for workaround.that should be straight and uipath also would not throw any error
Update: The solution I proposed, to append to List of objects, is required.
The alternative was to amend the VBA script to accept a list of strings, then convert one to integer, but that risks failure on data types inside the VBA on attempt to convert and I want to avoid that.
If anyone has a more elegant solution I’d be grateful.
I suspect that moving to newer version of .Net means that things have become more strict, so can’t assign to an array of objects where object types are different.
BUT isn’t that the whole point of using objects, that .Net doesn’t care what the object is and should therefore NOT be inferring the object types in the array { } string as the error message implies?
Would this impact AddDataRow using the ArrayRow property?
But for converting string to int you might not risk because you will already be passing an integer only but you will just do a .tostring or conversion to string which is already an integer type
I’d pass in as string, to overcome the .Net issue I’m facing then convert that to integer in the VBA script. But that moves the problem into the VBA where data types not enforced at coding, only run-time.
They probably did this because of the same issue, to ‘force’ split each argument out, so effectively a set of Append To List activities inside an Invoke VBA scope.
Not sure why it needed to be any different though to the interface for the argument mapping for Invoke Workflow or add log fields where you can create a table.
The new coding area interface for Studio just seems to take up an inordinate amount of unnecessary white space and space generally. It’s like they’ve made it look like a simple app on a phone for children. Hey ho.
Hi Peter, thanks for this. I’ve solved it with appending list of objects, but will try this as well - it uses the same method that I create lists of strings, should’ve thought of this myself!