After a year of trying to wrestle CLR.ahk into submission, with only moderate success, I'm asking for help.
If you have had success with third-party (i.e. not Microsoft and not COM enabled) DotNet DLLs and AHK, would you please provide examples of your code?
From my own experience, here are some that have worked and some that have not:
1) EPPlus works.
2) OpenTwebst works.
3) Vista-style FolderSelect works.
4) Docx/Xceed.Words.NET should work and fails miserably. The base object can be created, but no public methods or functions can be accessed.
5) WindowsFormsAero.dll works somewhat, but I haven't been able to create event handlers.
6) pythonnet(Python.Runtime.dll), for which I had great hopes, fails. The base object can be created, and the Runtime object can be created, but no public methods are available - not even 'PyRun_SimpleString'.
7) CS-Script, whose author and maintainer is extremely helpful, has a runtime DLL (CSScriptLibrary.dll). CS-Script runs, without a hiccup, the Docx.dll code that I tried from AHK. The assembly CSScriptLibrary itself can be created without problem using AHK/Clr.ahk. Creating CSScriptLibrary.CSScript, from where many public methods and functions are available, likewise. But not one of the public methods or functions will run. This was really a heartbreaker - CS-Script can run C#, VB, and JS, and can compile executables and DLLs. What a tool that would be to add to the AHK toolbox.
I have tried many other DotNet DLLs that I won't list (and many of which I no longer remember). Have any of you had luck with any of the libraries listed, or any others? All comments, suggestions, tutorials, links, etc. greatly appreciated.
Regards,
burque505
Help with CLR.ahk and 3rd-party DLLs
Re: Help with CLR.ahk and 3rd-party DLLs
This is interesting. Do you have examples? Maybe I can help.
Re: Help with CLR.ahk and 3rd-party DLLs
@TLM, sure! I followed your many helpful examples early on. I'll attach some sample files in a zip. I really appreciate it!
In about ten minutes I'll edit this post to add the files.
EDIT 1: WindowsFormsAero (dll included). Event handler problems.
EDIT 2: Docx, CS-Script, pythonnet, FolderSelect. FolderSelect works fine, included just for reference. I didn't put in EPPlus, but I posted a lot of examples for that on the forum and besides, it pretty much works.
Thanks again, I look forward to your insight.
Regards,
burque505
In about ten minutes I'll edit this post to add the files.
EDIT 1: WindowsFormsAero (dll included). Event handler problems.
EDIT 2: Docx, CS-Script, pythonnet, FolderSelect. FolderSelect works fine, included just for reference. I didn't put in EPPlus, but I posted a lot of examples for that on the forum and besides, it pretty much works.
Thanks again, I look forward to your insight.
Regards,
burque505
- Attachments
-
- For TLM.zip
- (419.51 KiB) Downloaded 177 times
-
- WinFormsAero.zip
- (39.5 KiB) Downloaded 166 times
Re: Help with CLR.ahk and 3rd-party DLLs
Is eventhandler.dll supposed to be a standard dll? It isn't in WinFormsAero.zip, and I get 0 for both isobject(helper) and isobject(helperAsm).
Cheers.
Cheers.
Re: Help with CLR.ahk and 3rd-party DLLs
@Helgef, @TLM, my apologies for leaving out the file from WindowsFormsAero. I put the wrong sample .ahk in the zip. I compiled EventHelper.dll instead of using the code from Lexikos's example inline in an include-style variable. Here it is with the compiled dll and the c# code, but I didn't have any luck with it. I just used Lexikos's code basically verbatim, and I think it needs to be tweaked. I didn't know how to handle the call to which is in the demo executable I compiled.
Code: Select all
dlg.ButtonClick += new EventHandler<ClickEventArgs>(dlg_ButtonClick);
- Attachments
-
- EventHelper files.zip
- (46.22 KiB) Downloaded 174 times
Re: Help with CLR.ahk and 3rd-party DLLs
I don't tend to call .NET libraries directly from AHK, I tend to write a thin C# wrapper designed to be called from AHK.
I think one of the few examples I have of AHK directly hitting a non-MS .NET library is AHK-ViGEm-Bus
Also, one thing to watch out for is blocked DLLs. AHK can silently fail when you try to load a DLL that still has download protection enabled, and I dunno how to detect it. In my own DLLs, I normally put an "OkCheck" function that returns "OK" to verify that I can call the DLL properly.
You can execute the powershell command Get-ChildItem -Path '.' -Recurse | Unblock-File as admin to unblock all DLLs in that folder and subfolders.
I think one of the few examples I have of AHK directly hitting a non-MS .NET library is AHK-ViGEm-Bus
Also, one thing to watch out for is blocked DLLs. AHK can silently fail when you try to load a DLL that still has download protection enabled, and I dunno how to detect it. In my own DLLs, I normally put an "OkCheck" function that returns "OK" to verify that I can call the DLL properly.
You can execute the powershell command Get-ChildItem -Path '.' -Recurse | Unblock-File as admin to unblock all DLLs in that folder and subfolders.
Re: Help with CLR.ahk and 3rd-party DLLs
@evilC, thanks for your input. My practice has been to compile the DLLs on my own machine, almost always from github source, although if a downloadable DLL is available I will always try both the downloaded library and the one I've compiled myself.
I applaud your C# wrapper practice - it was my idea to implement something similar using CS-Script as in intermediary, since it can run scripts, has a runtime DLL, and can compile executables and DLLs. Maybe it'd be worth it to you too to look at [ur=https://github.com/oleg-shilo/cs-script] CS-Script.[/url] I bet it's right up your alley.
Perhaps it's worth noting that AHK can create the base assembly for every one of these DLLs using Clr_LoadLibrary, and in a number of them the top-level engine using Clr_CreateObject (e.g. Python.Runtime.Runtime for Python.Runtime.dll. Maybe it's worth mentioning that, in this particular case, AHK reports back the CLSID, but the IID comes back empty).
Since I've had great success using CS-Script on all these DLLs that fail for me with AHK, I was hoping to call that one DLL - CSScriptLibrary.DLL - as an intermediate step. Unfortunately, I can't call its functions yet.
It seems a bit like apostasy, but is it possible that CLR.ahk is not 100% compatible with newer .NET implementations, or perhaps not 100% compatible with Roslyn? Unfortunately I don't have the knowledge to answer that on my own.
Regards,
burque505
I applaud your C# wrapper practice - it was my idea to implement something similar using CS-Script as in intermediary, since it can run scripts, has a runtime DLL, and can compile executables and DLLs. Maybe it'd be worth it to you too to look at [ur=https://github.com/oleg-shilo/cs-script] CS-Script.[/url] I bet it's right up your alley.
Perhaps it's worth noting that AHK can create the base assembly for every one of these DLLs using Clr_LoadLibrary, and in a number of them the top-level engine using Clr_CreateObject (e.g. Python.Runtime.Runtime for Python.Runtime.dll. Maybe it's worth mentioning that, in this particular case, AHK reports back the CLSID, but the IID comes back empty).
Since I've had great success using CS-Script on all these DLLs that fail for me with AHK, I was hoping to call that one DLL - CSScriptLibrary.DLL - as an intermediate step. Unfortunately, I can't call its functions yet.
It seems a bit like apostasy, but is it possible that CLR.ahk is not 100% compatible with newer .NET implementations, or perhaps not 100% compatible with Roslyn? Unfortunately I don't have the knowledge to answer that on my own.
Regards,
burque505
Re: Help with CLR.ahk and 3rd-party DLLs
Re the previous post, here's the code I used for creating a .docx file using DocX.dll (not included).
CS-Script has to be installed on the user's machine, which is probably a deal-killer for many.
I was hoping to do was supply the CS-Script runtime lib to avoid this.
(It also uses @GeekDude's code for hiding the cmd window.)
CS-Script has to be installed on the user's machine, which is probably a deal-killer for many.
I was hoping to do was supply the CS-Script runtime lib to avoid this.
(It also uses @GeekDude's code for hiding the cmd window.)
Spoiler
Re: Help with CLR.ahk and 3rd-party DLLs
Perhaps some progress. I found this AutoIt post by ptrex with a download containing dozens of CLR examples. Interestingly, it appears that AutoIt's CLR routines were cloned from from those of Lexikos that we use here, but with some notable additions I don't fully understand. (The use of Binding Flags to access non-public members was very interesting, to me anyway).
Okay, the following code produces the results below. I finally got event handling to work, although it's STILL not using 3rd-party DLL, but at least now I'm hopeful. You'll notice the EventHandler is basically just that used in Lexikos's original CLR post on event handling. I did, however, compile the DLL he suggested pre-compiling (creatively named "EventHelper.dll", and it is attached, along with a copy of the script.
I feel like I'm more excited than I should be, as this is something you can do in a heartbeat using only AHK. This is, however, a WinForms GUI, and not an AHK GUI, so now I'm having wild thoughts of creating complicated WinForms in VS 2017, and then writing AHK event handlers for the controls, and calling the whole shebang from AHK using CLR.ahk. I'm mainly encouraged by the fact I got an event handler to work AT ALL.
All comments, help, suggestions, extensions, expansions, modifications, customizations, etc. greatly appreciated.
Okay, the following code produces the results below. I finally got event handling to work, although it's STILL not using 3rd-party DLL, but at least now I'm hopeful. You'll notice the EventHandler is basically just that used in Lexikos's original CLR post on event handling. I did, however, compile the DLL he suggested pre-compiling (creatively named "EventHelper.dll", and it is attached, along with a copy of the script.
I feel like I'm more excited than I should be, as this is something you can do in a heartbeat using only AHK. This is, however, a WinForms GUI, and not an AHK GUI, so now I'm having wild thoughts of creating complicated WinForms in VS 2017, and then writing AHK event handlers for the controls, and calling the whole shebang from AHK using CLR.ahk. I'm mainly encouraged by the fact I got an event handler to work AT ALL.
All comments, help, suggestions, extensions, expansions, modifications, customizations, etc. greatly appreciated.
Spoiler
- Attachments
-
- AutoItIsh.zip
- (6.52 KiB) Downloaded 171 times
Re: Help with CLR.ahk and 3rd-party DLLs
You're my kind of crazy Carry on
Re: Help with CLR.ahk and 3rd-party DLLs
EDIT: @evilC, thanks for the encouragement. I meant to say that before but the latest spamfest intervened
Latest incarnation. The you are ell for TXTextControl is in the code. I compiled the dee ell ell from VS 2017.
EDIT: Editing works again. You'll notice there is no "save" or "open" on this, the TXTextControl used is the "express" version, which of course translates to express=crippled. Nonetheless, the whole thing was done in about 10 minutes with no AHK GUI code at all. Just objects created using CLR.ahk.
EDIT: Replaced defective ZIP.
Latest incarnation. The you are ell for TXTextControl is in the code. I compiled the dee ell ell from VS 2017.
EDIT: Editing works again. You'll notice there is no "save" or "open" on this, the TXTextControl used is the "express" version, which of course translates to express=crippled. Nonetheless, the whole thing was done in about 10 minutes with no AHK GUI code at all. Just objects created using CLR.ahk.
EDIT: Replaced defective ZIP.
- Attachments
-
- TXTextControl.zip
- (4.17 KiB) Downloaded 189 times