evilC / AutoHotInterception

An AutoHotkey wrapper for the Interception driver
MIT License
734 stars 66 forks source link

AHK v2 compatibility #34

Open ghost opened 5 years ago

ghost commented 5 years ago

I'm curious if this will be updated to be compatible with AHK v2, which is drawing ever closer to being the primary version.

It is actually possible to be compatible with both v1.1 and v2 if you make sure to use syntax and commands that work with both versions, as seen here: https://github.com/mmikeww/AHKv2-Gdip

evilC commented 5 years ago

I would not be surprised if it were compatible now.
AHI does not use very much in the way of AHK code, it's mostly C#
It would need a version of the CLR lib for AHK v2 (Which I think has been done?), but other than that, most of the AHK code uses classes and functions anyway (ie mostly expression syntax).

wwboynton commented 2 years ago

There were some breaking changes to v2 syntax that required some adjustment, but I have managed to get a v2 version partially working against AHK 2.0-a122-f595abc2. It is not thoroughly tested, and I can confirm there is an "interface not supported" error when trying to GetDeviceID, but no such issue when using GetDeviceIDByHandle. Once getting the id that way (or manually using the monitor), I can correctly set up a context manager and use it in a v2 #HofIf statement without issue. I have not tried using it in subscription mode yet.

I haven't converted the monitor (still running that against AHK v1.1.33.10).

@evilC you were correct in your assumption that no changes to the C# seemed to be necessary. I did use the CLR for AHK v2.0 lib available here.

I don't really have time to create a full proper release PR or write tests or anything, but if it's helpful I'm happy to share the work I did just getting the main AutoHotInterception.ahk file to be syntactically valid and (partially) functional. Just let me know if that would be useful or if someone's already doing it better.

evilC commented 2 years ago

@wwboynton my guess would be that it's a data type issue. GetDeviceID will be using an integer, whereas GetDeviceIDByHandle will be using a string.
Everything in AHK v1 is essentially a string, whereas AFAIK AHK v2 is type aware? I would guess that you may have similar issues if you tried to use subscription mode. Whatever, if it is what I think it is, should not be a problem to fix. Am happy to help with trying to complete it, I definitely see value in making this compatible with v2 - probs best to drop me a line on the AHI discord server

God-damnit-all commented 2 years ago

There were some breaking changes to v2 syntax that required some adjustment, but I have managed to get a v2 version partially working against AHK 2.0-a122-f595abc2. It is not thoroughly tested, and I can confirm there is an "interface not supported" error when trying to GetDeviceID, but no such issue when using GetDeviceIDByHandle. Once getting the id that way (or manually using the monitor), I can correctly set up a context manager and use it in a v2 #HofIf statement without issue. I have not tried using it in subscription mode yet.

I haven't converted the monitor (still running that against AHK v1.1.33.10).

@evilC you were correct in your assumption that no changes to the C# seemed to be necessary. I did use the CLR for AHK v2.0 lib available here.

I don't really have time to create a full proper release PR or write tests or anything, but if it's helpful I'm happy to share the work I did just getting the main AutoHotInterception.ahk file to be syntactically valid and (partially) functional. Just let me know if that would be useful or if someone's already doing it better.

I'd personally appreciate seeing your code for the AHKv2 conversion.

Is it being done in a way where it's also backwards-compatible, or is that not viable?

wwboynton commented 2 years ago

I'll have to look later if it's backwards compatible or not -- I ran it through a syntax converter to start and then just followed the trail for the remaining errors. I haven't tried executing it on v1 yet but I imagine there's probably a way for someone smarter than me to make it so. I haven't ever really used v1, so I'm not an expert in the arcane nuances of its syntax.

God-damnit-all commented 2 years ago

I'll have to look later if it's backwards compatible or not -- I ran it through a syntax converter to start and then just followed the trail for the remaining errors. I haven't tried executing it on v1 yet but I imagine there's probably a way for someone smarter than me to make it so. I haven't ever really used v1, so I'm not an expert in the arcane nuances of its syntax.

There's a syntax converter? Where at?

evilC commented 2 years ago

I would doubt that you could make one version of the AHK files that was backwards compatible, but it should be possible to have one DLL which is compatible with v1 and v2

God-damnit-all commented 1 year ago

I would doubt that you could make one version of the AHK files that was backwards compatible, but it should be possible to have one DLL which is compatible with v1 and v2

AHK v2 is now the default; a stable release came out at the end of December.