After finding it surprisingly easy to knock up JoystickWrapper, I was left thinking "Why stop at DirectInput and XInput"?
I found a really good tutorial that lets you get started with MEF without having to really understand too much. Example 4 (The advanced version) is particularly interesting - it shows how to rig up a plugin framework and have Intellisense working on the MetaData for the plugins.
I just used the handy refactor tools in Visual Studio, and built a POC for a plugin-driven version of JoystickWrapper which I dubbed InputWrapper.
Basically, a DLL that can load other plugin DLLs - each of which add support for different input types to AHK.
So, for example, the user uses CLR to load JoystickWrapper.dll, which searches it's plugin folder - in there, you put DirectInput.dll if you want DI support, a XInput.dll if you want XInput support, etc...
This would then let us easily plug in more exotic forms of input such as head trackers or VR trackers.
If I get that going, then I plan to try and make a custom GuiControl in C# that can interface with InputWrapper and query the plugin DLLs to see which devices are available and what inputs it has available - eg an InputButton GuiControl will query all plugins (DirectInput, XInput, RawInput etc) for what devices they have available that support buttons, and can then build a menu to allow the end-user to choose an input (or enter "bind mode" where they press the input).
Basically, the upshot should be that in AHK you add a GuiControl and pass it a callback, and the C# GuiControl handles binding and fires a callback to the AHK code when the input changes state.
Anyone else out there with experience in this area? Any sage words of wisdom?
Talk about things C#, some related to AutoHotkey
2 posts • Page 1 of 1
This build of InputWrapper is usable (From within C#, dunno how usable it is from AHK yet) - I haven't gotten all of the features of JoystickWrapper in yet (No Query methods), but all the subscription methods for DirectInput and XInput are implemented.