Communication between AutoIt and VBScript

[Nine]

56 minutes ago, argumentum said:

Kinky. Now, would you all post an "echo" script ?. One in AU3 and one in VBS as to show how the IPC would work in a MainLoop ?.
That way it'll be clear for someone with little knowing ( a.k.a. me ), how to go about implementing this as a 2 way IPC.
Thanks   

This is why I called it a proof of concept.  Maybe I'll work some more on this or maybe not.  But feel free to bring it a step further. 

[Professor_Bernd]

36 minutes ago, argumentum said:

Now, would you all post an "echo" script ?. One in AU3 and one in VBS as to show how the IPC would work in a MainLoop ?.

As I said, in the next days I want to study first the proposal of LarsJ, so here only briefly an approach in VBScript. Unfortunately I don't know how to open a file (pipe) for reading and writing at the same time, so I used two pipes. And unfortunately I don't know how to output a message in a loop in VBScript without blocking the loop. If I integrate it in PSPad, I can do an output that doesn't block the loop, but that's very complex and I'm already old  and can't focus on the COM ROT hint of LarsJ and on this pipe hint at the same time.

option explicit

Dim StartTime
Dim oFileSys, oTSF, sText

StartTime = Timer

Set oFileSys = WScript.CreateObject("Scripting.FileSystemObject")
Set oTSFOut = oFileSys.OpenTextFile("\\.\pipe\pipe_1", 2, True, 0)
Set oTSFIn = oFileSys.OpenTextFile("\\.\pipe\pipe_2", 1, True, 0)

do
  oTSFOut.WriteLine("Ceci est un test")
  sText = sText & oTSFIn.Readline()
  WScript.Sleep(50)
loop until (Timer - Starttime) > 10 ' runs for 10 seconds

oTSFOut.Close
oTSFIn.Close()

MsgBox(sText & vbCRLF)

Since I don't have an .au3 counterpart, the code is untested. Maybe Nine might write a .au3 counterpart to use the pipes in a loop?

[Nine]

30 minutes ago, Professor_Bernd said:

Maybe Nine might write a .au3 counterpart to use the pipes in a loop?

I must admit I might get tempted.  But could you explain how the communication (in your particular situation) is to be performed between both processes.  What process initiate the first write, what is the response back.  It would help me understand what it should be aimed for.  Thanks.

[GokAy]

You could find this easily by yourself but here it goes

https://docs.microsoft.com/en-us/windows/win32/ipc/named-pipes

[Professor_Bernd]

@Nine

For best understanding, it's best to look directly at my project "PSPad4AutoIt3". I have created a Quick&Dirty test version, which does NOT necessarily work error-free and in which NOT all descriptions are correct. You can download it here.

I have highlighted the relevant parts as best I can and concentrated the code in one place if possible:

"...\PSPad4AutoIt3\PSPad4Au3\Script\VBScript\AutoIt3_CallTip.vbs" see "Sub CallTip_Show()",

"...\PSPad4AutoIt3\PSPad4Au3\Au3 scripts\CallTipViewer.au3" see "Func Main_Function()" and above.

In this test version I experimented with MailSlot from trancexx and I only managed to get the communcation direction from VBScript to AutoIt. This is a good starting point.

Notes:

• In the stable version I implemented all communication between VBScript and AutoIt with AutoItX. This works great, but is not portable. AutoItX needs a registration via regsvr32.exe. This is the reason why I need another communication between VBScript and AutoIt.
• For your tests you can think of it as replacing all commands that use AutoItX. You can find the corresponding places if you search for "oAutoItX". For your tests you can of course use your own commands.

Ok, as you can see, this is quite complicated. That's why I haven't created a demo yet. From the feeling I think that the tip of LarsJ with COM and ROT has bigger chances of success. If you want to help with this instead of the named pipes, you can find the links in the first posting. You can of course decide for what you want. I am glad about any help! 

 

Edit: Oh, I forgot!

16 hours ago, Nine said:

What process initiate the first write, what is the response back.

It's all about the CallTips. To test, open any .au3 in PSPad4AutoIt3, place the caret in the parentheses of a function and press Ctrl+Shift+Space. Then a CallTip will appear. If you run left or right with the arrow keys from your keyboard, the CallTip will update when the caret gets into another parameter. If you run through it quickly, you can see the delay.

The first write is initiated by "...\PSPad4AutoIt3\PSPad4Au3\Script\VBScript\AutoIt3_CallTip.vbs" in "Sub CallTip_Show()" if you press Ctrl+Shift+Space.

The response back at the moment is to query whether the CheckBox is checked. See line 394

Loop While oAutoItX.ControlCommand(gc_sTitel_CallTipWin, "", "Button1", "IsChecked", "") = 1 ' 1 = checked, 0 otherwise.

Edited December 20, 2020 by Professor_Bernd

[Professor_Bernd]

Two more tips:

• I've included a help file in PSPad that appears when you press F1 in a .vbs file.
• In PSPad you can display info in the loop without blocking the loop with

logAddLine("MyData")

The data will be displayed in the console (LogWin).

[LarsJ]

I've downloaded your test project. Certainly not mainstream AutoIt code. Interesting.

I've quite briefly tested the code with CallTips on Windows 7 as described above. I'm not immediately able to identify performance issues when using right/left arrow keys to navigate from one parameter to another. The information in the CallTip window appears to be updated without any problems.

Are you aware of the performance issue discussed here. The issue is current on newer versions of Windows 10 as soon as a GUI element appears on the screen. Subsequently, all AutoIt code (GUI-related or not) in the same process is affected by the issue. But the problem does not affect Windows 7.

[Professor_Bernd]

13 minutes ago, LarsJ said:

I've downloaded your test project. Certainly not mainstream AutoIt code. Interesting.

Thank you very much! It's quite hard, because I have to program in VBScript and AutoIt at the same time, and take into account the peculiarities of PSPad. At the beginning it almost drove me crazy to switch between AutoIt = very powerful, very comfortable and VBScript = very little powerful, very inconvenient. But VBScript is the only interface in PSPad.

25 minutes ago, LarsJ said:

Are you aware of the performance issue discussed here.

Yes, I followed the discussion at the beginning, but now I didn't think about it. It could be possible that this plays a role. But it's not as important in my "MailSlot" attempt as that I only got the communication between VBScript and AutoIt to work in 1 direction.

Today I've been studying your code "Implementing IRunningObjectTable Interface" for a couple of hours. I am so excited about it!  I've already done a few tests outside of my project to understand how it works. I think I understood the basic principle and I'm no stranger to dictionaries.

I hope in the next few days I'll get around to adding your code to my project to see if the communication is fast enough so that this performance issue on Windows 10 has as little impact as possible.

If this all works, PSPad4AutoIt3 will be completely portable! Yay!

[Professor_Bernd]

Tests with the first 4 instructions were successful!

The calls to these commands can be found in these files

• "...\PSPad4AutoIt3\PSPad4Au3\Script\VBScript\AutoIt3_CallTip.vbs" - search for lines with "oCOM_Dict".
• "...\PSPad4AutoIt3\PSPad4Au3\Au3 scripts\CallTipViewer.au3" - search for lines with "$g_oDict_COM_CallTip".

I have created a test version in which I changed the 4 most important different instructions from AutoItX code to IROT code. With this, the basic functionality is created enough that it might be possible to change the remaining 16 or so different instructions as well.

The first 4 statements are related to data exchange between VBScript and AutoIt. Thereby it is transmitted: The text lines to the left and above the caret, internal and external caret position, path of the file of the active editor and an indicator showing the visibility of the CallTipWin.

The about 16 different other statements execute AutoItX commands which are not used for data exchange between VBScript and AutoIt, but which which independently retrieve information, such as WinExists, WinGetHandle, WinGetTitle, etc. For this a different concept has to be created, which means an corresponding effort.

The speed is good, but I have the feeling it could be improved. Meant is the speed with which the caret can be moved with the arrow keys in the line, while a CallTip is displayed. Maybe someone has an idea how to increase the speed?

[Professor_Bernd]

@LarsJ

Is it possible to register ActiveX DLLs in ROT without using regsvr32?

My idea would be to use a copy of AutoItX3.dll in my portable application. It should be registered when the first instance of my application starts and deregistered when the last instance of my application closes. It is important to me that the portable use of the AutoItX3.dll does NOT affect the user's normally registered AutoItX3.dll.

[LarsJ]

You can create the ActiveX object this way without registering the file:

$sIID = Default
$sCLSID = "{2E93307E-777D-49E4-886A-D5B04470796A}"
$hActiveX = DllOpen(@ScriptDir & "\HexEdit.ocx")
$oHexEdit = ObjCreate($sCLSID, $sIID, $hActiveX)

It's demonstrated by ptrex in this example. I think this technique also works even if your object is defined in a dll file. Then you can register the object in the ROT.

[mLipok]

43 minutes ago, LarsJ said:

You can create the ActiveX object this way without registering the file:

$sIID = Default
$sCLSID = "{2E93307E-777D-49E4-886A-D5B04470796A}"
$hActiveX = DllOpen(@ScriptDir & "\HexEdit.ocx")
$oHexEdit = ObjCreate($sCLSID, $sIID, $hActiveX)

It's demonstrated by ptrex in this example. I think this technique also works even if your object is defined in a dll file. Then you can register the object in the ROT.

This is technique provided by @trancexx long time ago:

; Object identifiers
Global Const $sCLSID_OleDocumentProperties = "{58968145-CF05-4341-995F-2EE093F6ABA3}"
Global Const $IID_OleDocumentProperties = "{58968145-CF01-4341-995F-2EE093F6ABA3}"

$sDll = "dsofile.dll" ; location and name of your dll
$hDll = DllOpen($sDll) ; open it

; Experimenal feature. Try with newer versions of AutoIt
$oObj = ObjCreate($sCLSID_OleDocumentProperties, $IID_OleDocumentProperties, $hDll)

; Check for errors and work with object
;...

I use this technique in my QuickPDF.au3 UDF and many others UDF.

But I just found another one:

$sDll = @SystemDir & "\ImageMagickObject.dll" ; or just name
$aCall = DllCall($sDll, "long", "DllRegisterServer")
If @error Or $aCall[0] Then MsgBox(262144, "ERROR", "Failed to register " & FileGetLongName($sDll))

... here:

 

But now I have a question to @LarsJ why you are using this following statement in this way:

43 minutes ago, LarsJ said:

$sIID = Default

instead providing desired IID GUID  ?

 

Edited January 3, 2021 by mLipok

[Professor_Bernd]

Hello LarsJ.

Very interesting tip! If I get your tip to work, it opens up incredible possibilities.

Previously, with your help, I registered a dictionary object in ROT that allows communication between my VBScript and my AutoIt script. With this I was able to implement 4 functions that are used to exchange data between VBScript and Au3.

Then there are almost 20 different functions that are executed in the VBScript via AutoItX object. These functions do not serve the data exchange, but should be executed directly in the VBScript (e.g. WinGetHandle(), ControlGetFocus(), ...). The goal is to make my project fully portable, so I don't want to use AutoItX which is registered in the Windows system (regsvr32). Therefore I started a week ago to convert as much AutoItX code as possible from my VBScript to my Au3. I want to finish that first before trying another option.

So far it's going quite well and I guess I'll be done with it next month. (If it doesn't work, sooner of course.)  After that, I'll try to get into the above code from you and ptrex (I've already had a quick look at it, looks amazing!) I'd be very happy if it then works out to use AutoItX without registration in the system (regsvr32) in my VBScript. Then it would be perfect!

But one thing at a time! Thanks a lot for your tip.

[Professor_Bernd]

Hello mLipok.

Your tip with the code from trancexx looks interesting too. Is that then also a COM object registered in the ROT? My knowledge about COM and ROT is not very big, but I know now that the communication via a COM ROT object, which LarsJ enabled me to do, is fast, while COM objects from trancexx were too slow. But this may be due to me, if I did not implement the code of trancexx correctly. What I tried was for example "Access AutoIt".

Thanks a lot for your hints! 👍

[LarsJ]

Professor_Bernd, The code by trancexx does not register the objects in the ROT. You have to do that with my code.

mLipok, I just copied directly from the code by ptrex.

[mLipok]

So @ptrex is the one who can answer on my question .

 

[Professor_Bernd]

15 hours ago, LarsJ said:

The code by trancexx does not register the objects in the ROT. You have to do that with my code.

Thanks for the info! That saves me a lot of time that I would have needed for testing. 👍

[JockoDundee]

1 minute ago, Professor_Bernd said:

Thanks for the info! That saves me a lot of time that I would have needed for testing. 👍

Prof, one question... Are you using Autoit in this project solely for its win32 api capabilities?

In other words, if you were able to you would prefer it to all be in VBS?

(ok that’s two questions)

[Professor_Bernd]

Short answer to both questions: Yes.

Somewhat more detailed answer. It is about two problems related to VBScript:

1. The communication between VBScript and AutoIt. This problem was actually what this thread was about and it could be solved with the help of LarsJ's tip in another thread,  that linked to his code ROT objects and this example. So the actual problem of this thread is solved.
2. But in my project, there is a second problem that you touched on: Using Win32 api capabilities in VBScript (e.g. WinGetHandle(), ControlGetFocus(), ...). This has been done so far using AutoItX, but AutoItX usually needs to be registered in the system (regsvr32). My project, however, is now intended to become fully portable and work without registration via regsvr32. I am currently working on this problem.

36 minutes ago, JockoDundee said:

if you were able to you would prefer it to all be in VBS?

I would be very happy if there were possibilities for this.

[ptrex]

@Professor_Bernd   

This is an example of how portable you can go using VBScript and ActiveX

Using Lars his technique combined with the rest if the AutoIT portable techniques