Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

AHK v2 compatibility #34

Open
ghost opened this issue Apr 12, 2019 · 8 comments
Open

AHK v2 compatibility #34

ghost opened this issue Apr 12, 2019 · 8 comments
Labels
enhancement New feature or request

Comments

@ghost
Copy link

ghost commented Apr 12, 2019

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

@ghost ghost changed the title AHK2 compatibility AHK v2 compatibility Apr 12, 2019
@evilC evilC added the enhancement New feature or request label Apr 13, 2019
@evilC
Copy link
Owner

evilC commented Apr 13, 2019

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
Copy link

wwboynton commented May 16, 2022

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
Copy link
Owner

evilC commented May 16, 2022

@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

@ImportTaste
Copy link

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
Copy link

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.

@ImportTaste
Copy link

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
Copy link
Owner

evilC commented May 18, 2022

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

@ImportTaste
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants