Import object arguments


#1

I have two projects

the first project gets data from an excel file (into an object) and create two data dictionaries
the second will process the information of my object( which has the excel information) and the dictionaries

I invoke my second proyect and define as arguments my object and the 2 dictionaries because I need to pass these values to the second.

However, When I write in the second project Object(1).Tostring (to display my first row) into a message box there is shown a error.

Is it possible to pass object information and data dictionary to other workflow throw “Invoke workflow file” activity ?


#2

I saw your related question on a different topic and replied there:

If you have further questions, please post them here :slight_smile:


#3

@sfranzen, I believe you are an expert on this topic. I’d like to ask a question:

I’m trying to integrate AutoHotkey scripts into UiPath. I can do it from VB.Net without much trouble, using both Interop.AutoHotkey.dll and AutoHotkey.dll, using both early and late binding. I see from your posts that late binding won’t work in UiPath.

Building off a workflow that @TDagsvik sent me, I’m loading System.Windows.Forms and AutoHotkey assemblies, and using Invoke Code into UiPath. Using “step into”, my code runs fine until the Invoke Code executes, and i get a late binding error at line 1. I’m attaching my non-functional attempt and the workflow @TDagsvik sent (which I found to be a great example of how to write and annotate a workflow, by the way).
Turn_ScrollLock_Off.xaml (12.6 KB)
Ahk attempt.xaml (9.8 KB)

If you have time, I would love to find my around this bottleneck.

(I have experimented with the Run Auto Hot Key Script [sic] activity, but all I seem to be able to do is load an existing script and run it. The script I called for test purposes is dirt simple. Run from the command prompt, the script “HelloVariable.ahk” with the argument “hello” - no quotes anywhere - takes the argument and displays it in a message box. it works fine (as you can see, I’ve got .ahk files associated with AutoHotkey.exe on my machine)
.

C:\>HelloVariable.ahk hello

When I load the same script in a Run Auto Hot Key Script activity, I can add arguments from the bar below the workspace, but the script doesn’t see them. When I add an argument from the Properties panel, it throws an error and I get the dreaded red exclamation mark. AutoHotkey is basically off the radar in the forum, with good reason I suppose, but it does not seem to me that the Run Auto Hot Key Script activity is giving access to any of the true capability of AutoHotkey.dll. To get data in and out you have to save it to and retrieve it from the file system, which works and is really speedy, contrary to my expectations, but that’s not very elegant. I don’t know if it is of any use, but that script HelloVariable.ahk is attached also in a zip file.)

HelloVariable.zip (434 Bytes)
Ahk attempt two.xaml (4.8 KB)

Thread with @TDagsvik’s post


#4

Well, expert is quite too much honor I think. :stuck_out_tongue: I would say I understand computers and programming concepts quite well; sometimes I joke that I understand them better than I do humans. Therefore I have an easier time understanding exception messages, finding and understanding the technical documentation, stackoverflow answers and such. Most of what I know about VB comes from doing just that while using UiPath and answering some questions here. I haven’t written any significant code in it, and if I were to program in .NET it would probably be in C#.

That being said, I’m also unfamiliar with AutoHotKey, but maybe I will look into it and find use for it. I did get the script activity to work, so thanks for the quick example file. For the argument passing to work, you have to include function definitions in the script, so for example

DisplayBox(msg) {
    msgbox, Hello %msg%
}

This can then be called using the activity with “DisplayBox” as the function name and a single string argument as parameter. You could probably also run the actual script by assembling a command line string and using that with the Powershell Command activity with “IsScript” checked.

As for the late binding error, it is once again because a call is made to a specific class method on a generic Object variable. To resolve it, you have to declare it as its actual type, which would require properly importing its namespace in Studio, which would probably require making a special package for the DLL file or modifying workflow code by hand, extra effort that may not be worth it.