Test build - InputHook, long paths, switch-case

Community news and information about new or upcoming versions of AutoHotkey
User avatar
Relayer
Posts: 160
Joined: 30 Sep 2013, 13:09
Location: Delaware, USA

Re: Test build - InputHook, long paths, switch-case

30 Apr 2019, 08:36

All,

I am simply grateful for any effort Lexikos puts into either version. I use v1 but understand the importance of v2 if AHK is to have a future. It requires incredible attention to detail to create code that functions well. There are many things we all *should* do but motivation is a strange thing. I don't think it is useful to comment on how a volunteer should apply their time. We all know that if Lexikos were to move away from AHK we may not find another person willing to expend the effort he has put into this product. I hope to simply express my sincere gratitude for the hard work and hope that that provides a morsel of motivation to continue. This may sound corny but I look to the forum "Announcements" from Lexikos with excitement.

Relayer
User avatar
oldbrother
Posts: 273
Joined: 23 Oct 2013, 05:08

Re: Test build - InputHook, long paths, switch-case

01 May 2019, 13:26

joedf wrote:
22 Apr 2019, 09:17
Very nice!
I like the ability to specify multiples case 2a, 2b:.
I just wonder happens if I have something like so:

Code: Select all

switch(value)
{
  case 1:
  case 2, 3: msgbox hi
  default: msgbox default
}
Does it simply do nothing when value==1?
:thumbup: :thumbup: :thumbup:
User avatar
kczx3
Posts: 1640
Joined: 06 Oct 2015, 21:39

Re: Test build - InputHook, long paths, switch-case

01 May 2019, 20:49

Relayer wrote:
30 Apr 2019, 08:36
All,

I am simply grateful for any effort Lexikos puts into either version. I use v1 but understand the importance of v2 if AHK is to have a future. It requires incredible attention to detail to create code that functions well. There are many things we all *should* do but motivation is a strange thing. I don't think it is useful to comment on how a volunteer should apply their time. We all know that if Lexikos were to move away from AHK we may not find another person willing to expend the effort he has put into this product. I hope to simply express my sincere gratitude for the hard work and hope that that provides a morsel of motivation to continue. This may sound corny but I look to the forum "Announcements" from Lexikos with excitement.

Relayer
Not corny at all. I am the same way!
0x00
Posts: 89
Joined: 22 Jan 2019, 13:12

Re: Test build - InputHook, long paths, switch-case

10 May 2019, 06:26

:superhappy: , so good, about time we had SWITCH, InputHook's rad as well, so cheers for still making such major improvements to those of us still in v1. :salute: :thumbup:
Randy31416
Posts: 58
Joined: 15 Jan 2014, 19:09

Re: Test build - InputHook, long paths, switch-case

10 May 2019, 09:04

Switch is very nice addition, and I too would welcome it in V1 (so that I could go back to using a regular rather than a test version of AutoHotkey).
User avatar
evilC
Posts: 4823
Joined: 27 Feb 2014, 12:30

Re: Test build - InputHook, long paths, switch-case

04 Nov 2019, 11:08

@lexikos could we get OnKeyUp for InputHook as well as OnKeyDown?
I am looking into the possibility of using InputHook to write a dynamic hotkeys solution, however the current implementation does not seem to be great for allowing multi-key combos - eg if trying to bind A + B, the code has no way of knowing if a third key will also be pressed and whether to end or not. My existing dynamic hotkey solutions end as soon as a key is released, hence the desire for OnKeyUp. No need to change the params for the callbacks, I can just function bind to allow one function to handle press and release
Unless I am missing something?
Of course, I could write code that declares a release hotkey for each key that was pressed or something, but having it all supported by InputHook would be preferable

As a secondary request, will mouse buttons ever be implemented for InputHook?
User avatar
evilC
Posts: 4823
Joined: 27 Feb 2014, 12:30

Re: Test build - InputHook, long paths, switch-case

04 Nov 2019, 14:20

Also, there seems to be a problem with InputHook and classes:

Assigning ih to local variable, then to property works (However note that inputHook is not passed to OnKeyEvent as it is with a normal function)

Code: Select all

kb := new KeyBinder()
kb.Start()

class KeyBinder {
	__New(){
		ih := InputHook()
		ih.KeyOpt("{All}", "SN")
		ih.KeyOpt("{NumLock}", "-S")
		ih.OnKeyDown := this.OnKeyEvent.Bind(this, 1)
		this.ih := ih
	}
	
	Start(){
		this.ih.Start()
	}
	
	Stop(){
		this.ih.Stop()
	}
	
	OnKeyEvent(keyState, vk, sc){
		keyName := GetKeyName(Format("vk{:x}sc{:x}", VK, SC))
		ToolTip % "VK: " vk ", SC: " sc ", Name: " keyName ", State: " keyState
	}
}
Assigning ih to class property immediately does not work:

Code: Select all

kb := new KeyBinder()
kb.Start()

class KeyBinder {
	__New(){
		this.ih := InputHook()
		this.ih.KeyOpt("{All}", "SN")
		this.ih.KeyOpt("{NumLock}", "-S")
		this.ih.OnKeyDown := this.OnKeyEvent.Bind(this, 1)
	}
	
	Start(){
		this.ih.Start()
	}
	
	Stop(){
		this.ih.Stop()
	}
	
	OnKeyEvent(keyState, vk, sc){
		keyName := GetKeyName(Format("vk{:x}sc{:x}", VK, SC))
		ToolTip % "VK: " vk ", SC: " sc ", Name: " keyName ", State: " keyState
	}
}
This may be intentional, or unavoidable, in which case it would probably bear mentioning in the docs, it took some head-scratching to figure out how to get it to work ;)
Last edited by evilC on 04 Nov 2019, 14:42, edited 1 time in total.
User avatar
evilC
Posts: 4823
Joined: 27 Feb 2014, 12:30

Re: Test build - InputHook, long paths, switch-case

04 Nov 2019, 14:23

Here is a demo of a Bind Mode routine for a Dynamic Hotkeys system using InputHook
I implemented my own detection for key release

Code: Select all

/*
Demo of using InputHook to power a Dynamic Hotkeys system
*/
#SingleInstance force
OutputDebug, DBGVIEWCLEAR

kb1 := new KeyBinder()
kb2 := new KeyBinder()
Gui, Show,, KeyBinder
return

GuiClose:
	ExitApp

class KeyBinder {
	__New(){
		Gui, Add, Edit, hwndhwnd xm w200 Disabled
		this.hKeyName := hwnd
		Gui, Add, Button, hwndhwnd x+5 yp-1, Bind
		fn := this.Start.Bind(this)
		GuiControl +g, % hwnd, % fn
		this.ih := InputHook()
		this.ih.KeyOpt("{All}", "SN")
		this.ih.OnKeyDown := this.OnKeyEvent.Bind(this, 1)
	}
	
	Start(){
		this.KeyWatchTimers := {}
		this.BoundKeys := []
		GuiControl, , % this.hKeyName, Press key(s) to bind...
		this.ih.Start()
	}
	
	Stop(){
		this.ih.Stop()
		for keyName, fn in this.keyWatchTimers {
			Log("Stopping timer for " keyName)
			SetTimer, % fn, Off
		}
		Loop % this.BoundKeys.Count() {
			StringUpper, key, % this.BoundKeys[A_Index]
			str .= key
			if (A_Index != this.BoundKeys.Count()){
				str .= " + "
			}
		}
		GuiControl, , % this.hKeyName, % str
	}
	
	OnKeyEvent(state, ih, vk, sc){
		keyName := GetKeyName(Format("vk{:x}sc{:x}", VK, SC))
		if (state && this.KeyWatchTimers[keyName]){
			return
		}
		Log("OnKeyEvent - VK: " vk ", SC: " sc ", Name: " keyName ", State: " state)
		if (state){
			this.BoundKeys.Push(keyName)
			cb := this.OnKeyEvent.Bind(this, 0, ih, vk, sc)
			fn := this.WatchKey.Bind(this, keyName, cb)
			this.KeyWatchTimers[keyName] := fn
			SetTimer, % fn, 100
		} else {
			this.Stop()
		}
	}

	WatchKey(keyName, cb){
		if (!GetKeyState(keyName, "P")){
			cb.Call()
		}
	}
}

Log(text){
	OutputDebug % "AHK| " text
}
Image
Last edited by evilC on 05 Nov 2019, 11:29, edited 2 times in total.
lexikos
Posts: 9583
Joined: 30 Sep 2013, 04:07
Contact:

Re: Test build - InputHook, long paths, switch-case

05 Nov 2019, 06:08

evilC wrote:
04 Nov 2019, 11:08
@lexikos could we get OnKeyUp for InputHook as well as OnKeyDown?
Probably; see InputHook (Wish List).
As a secondary request, will mouse buttons ever be implemented for InputHook?
Not in the near future.


Your "works" example does not work for me with v1.1.31.01, because contrary to what you say, the InputHook is passed as a parameter.

Your "does not work" example has exactly the same behaviour, as far as I can tell.

It seems that your last example relies on InputHook being passed as a parameter.
User avatar
Frosti
Posts: 426
Joined: 27 Oct 2017, 14:30
Contact:

Re: Test build - InputHook, long paths, switch-case

23 Nov 2019, 07:18

Thx, Lexikos

for Inputhook ()! I have just discovered this new possibility. Great new feature!
With that, I've discovered a wonderful way to get more confidence in my autocomplete features and get more options to customize them.
The fact is that I have finished completing the development of the autocomplete functions frustrated.
Thanks again.

Here is a little code example which one can do better.
In this script a part of a text (in an edit control) is selected and not selected again.
This draws the user's attention to the input required here.
The input hook stops flashing immediately after the first key is pressed (INPUTHOOK).

Code: Select all

	global UserInput:= false

	hMuster16:= WinExist("Muster 16 ahk_class #32770")
	WinActivate   	, % "ahk_id " hMuster16
	WinWaitActive	, % "ahk_id " hMuster16
	ControlFocus 	, % "Edit8", % "ahk_id " hMuster16
	ControlGetText	, text, % "Edit8", % "ahk_id " hMuster16

	select	:= "..."
	cpos 	:= InStr(text, select) - 1
	turn  	:= 0
	back 	:= false
	mLen	:= StrLen(text) - 1
	SelW 	:= StrLen(select)
	
	ih := InputHook("L1 V M")
	ih.NotifyNonText	:= true
	ih.VisibleText     	:= true
	ih.OnKeyDown      	:= Func("OnKeyDown")
	ih.Start()


	Loop 50
	{
		SendMessage 0xB1, % cpos, % cpos+3, Edit8, % "ahk_id " hMuster16 ; EM_SETSEL
		if InterruptableSleep(150)
			break
		SendMessage 0xB1, % cpos, % cpos, Edit8, % "ahk_id " hMuster16 ; EM_SETSEL
		if InterruptableSleep(150)
			break
	}

	ih.Stop()

	SendMessage 0xB1, % cpos, % cpos+3, Edit8, % "ahk_id " hMuster16 ; EM_SETSEL

return

InterruptableSleep(time) {

	Loop, % time/5
	{
		Sleep, 5
		If UserInput
			break
	}

	If UserInput
		return true
}

OnKeyDown() {
UserInput:=true
}

Return to “Announcements”

Who is online

Users browsing this forum: No registered users and 3 guests