Page 1 of 1
CHotkeyControl - a replacement for AHK's Hotkey GuiControl
Posted: 02 Aug 2015, 17:59
by evilC
CHotkeyControl aims to provide a feature-rich replacement for AHK's Hotkey GuiControl that is capable of recognizing any binding that AHK's hotkey system supports - with options for setting pass-through (~), Wild (*) etc.
It uses SetWindowsHookEx DLL calls to simultaneously read and block input from being seen by other apps.
It is currently a work in progress, but the basics are operational.
Re: CHotkeyControl - a replacement for AHK's Hotkey GuiControl
Posted: 03 Aug 2015, 18:11
by evilC
Massive update - loads of fixes and optimizations.
I think it is now pretty much ready for use, gonna start trying to use it in some of my projects.
Re: CHotkeyControl - a replacement for AHK's Hotkey GuiControl
Posted: 04 Aug 2015, 14:43
by evilC
We made a major usability improvement.
The control is now a ComboBox, and we use a "Cue Banner" to display the currently selected hotkey.
Re: CHotkeyControl - a replacement for AHK's Hotkey GuiControl
Posted: 05 Aug 2015, 10:05
by evilC
Another major change - bind mode now only ends on an up event.
Although slightly less user-friendly, it does make the whole thing a lot simpler, and open some doors.
For example, if you end bind mode on the down event, and bind the hotkey at that point, when the user releases the key, the up event for that hotkey will be fired.
You don't seem to be able to do a GetKeyState loop to wait for the key just bound to be released however, I guess because we are hooking and blocking the keys, so AHK didn't see the key go down.
Also we cannot end bind mode on the down event of a non-modifier if we wish to support hotkeys such as a + b
Re: CHotkeyControl - a replacement for AHK's Hotkey GuiControl
Posted: 07 Aug 2015, 18:04
by KuroiLight
Finally got around to testing it. Works and its close to what I had in mind.
If you dont want to block input globally you can instead add
Code: Select all
OnMessage(0x100, "BlockDing")
BlockDing() {
if(A_Gui == YourGuiId)
return 1
}
to avoid the ding windows does.
Re: CHotkeyControl - a replacement for AHK's Hotkey GuiControl
Posted: 08 Aug 2015, 05:20
by evilC
Hmm, interesting idea. My original forays into SetWindowsHookEx were a result of trying to re-write AHK's hotkey system, so for that I needed global hooks. But I suppose for the bind routine, then yeah, you only need to hook inside the application.
Also, new version uploaded - now has basic support for Joystick buttons.
Re: CHotkeyControl - a replacement for AHK's Hotkey GuiControl
Posted: 08 Aug 2015, 19:27
by KuroiLight
What I meant was that you can keep you global hook but instead of returning 1 (and blocking all user input) you can add that code and windows wont ding while keys are being pressed inside the window.
Re: CHotkeyControl - a replacement for AHK's Hotkey GuiControl
Posted: 03 Dec 2015, 07:11
by titep
It works great, but when I embed the code of CHotkeyControl into my .ahk file, CHotkey make Morse() goes wrong.
For example, when I hit my key binding three times (captured with Morse()), its return to 000 and 0 instead of 000 only.
@@ What happened?
Re: CHotkeyControl - a replacement for AHK's Hotkey GuiControl
Posted: 03 Dec 2015, 08:03
by evilC
Morse() works with AHK hotkeys. CHotkeyControl does not use AHK's hotkey system *at all*, it is entirely reliant on low-level windows hooks.
Therefore CHotkeyControl is totally incompatible with Morse()
Re: CHotkeyControl - a replacement for AHK's Hotkey GuiControl
Posted: 04 Dec 2015, 03:51
by titep
@evilC : Thank you, I am just trying to capture word I type like Typing Aid. I use input and loop function to capture letter by letter and then combine them into word. When I type fast, my ahk works unrealiably. That's why I came to CHotkeycontrol ಠ_ಠ Maybe I will try another way...
Re: CHotkeyControl - a replacement for AHK's Hotkey GuiControl
Posted: 04 Dec 2015, 07:42
by evilC
I have pretty much abandoned the low-level hook technique (as used in CHotkeyControl) now, because the application becomes un-debuggable while the hooks are running (key / mouse stops working so you can't step through).
So instead I just map a hotkey to every key on the keyboard, like this:
Code: Select all
CreateHotkeys(){
static pfx := "$*"
critical on
; Cycle through all keys / mouse buttons
Loop 256 {
; Get the key name
i := A_Index
code := Format("{:x}", A_Index)
n := GetKeyName("vk" code)
if (n = "")
continue
fn := this.KeyPressed.Bind(this, n)
hotkey, % pfx "~" n, % fn, % "On"
}
critical off
}
KeyPressed(n){
; key went down - caveat: may be a repeat though if key is held
; n holds the name of the key
}
Re: CHotkeyControl - a replacement for AHK's Hotkey GuiControl
Posted: 04 Dec 2015, 19:10
by KuroiLight
Might I ask what debugger you're using? I haven't been using one thus far.
Re: CHotkeyControl - a replacement for AHK's Hotkey GuiControl
Posted: 05 Dec 2015, 08:49
by evilC
Scite4Autohotkey
Re: CHotkeyControl - a replacement for AHK's Hotkey GuiControl
Posted: 09 Apr 2017, 16:18
by runie
Hi evilC.
Would it be possible making it function more as a normal hotkey control?
For example:
- - Clicking on the hotkey control starts the binding mode
- The control text updates while you input your hotkey
- Pressing Escape on the control clears the hotkey
This would obviously "bypass" the options of using the pass-through and wildcard options, but for my uses it doesn't seem to be necessary.
Using escape as a "cancel" would also remove the possibility of binding escape.
I love the functionality but don't really like the way the user has to input a hotkey.
o/
RUNIE
Re: CHotkeyControl - a replacement for AHK's Hotkey GuiControl
Posted: 25 Jun 2017, 08:27
by evilC
Sorry it took so long to reply.
This code was a result of my tinkerings on my path to making UCR.
I since took the technique that I ended up using for UCR and implemented it as a
stand-alone library
It sounds like this would fit your needs?
If you do not want to use AHK_H, I am working towards a solution using C# as the back-end, and that would work from AHK_L, stay tuned...