Page 1 of 2

Test build - InputHook, long paths, switch-case

Posted: 22 Apr 2019, 02:09
by lexikos
v1.1.30.03-4+gdd14232 | installer

Added InputHook(), like the Input command but much more flexible.

The downloads include detailed documentation, including a comparison of InputHook to Input.

I have manually uploaded the documentation (not yet integrated): InputHook, Switch

Also included in the test build (same as previous test build):
  • Incomplete support for long path awareness.
  • Experimental switch-case statement.

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

Posted: 22 Apr 2019, 06:41
by Helgef
Regarding InputHook, well done :thumbup: (judged by the documentation only (for now)).
v2
Regarding switch :thumbup:

Cheers.

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

Posted: 22 Apr 2019, 07:13
by HotKeyIt
That is looking very good, many thanks :thumbup:
Input vs InputHook says The Input command limits the length of the input to 16383, while InputHook limits it to 1023. but InputHook help says: If unspecified, the length limit is 16383..

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

Posted: 22 Apr 2019, 09:04
by JoeWinograd
> Experimental switch-case statement.

Very nice! :thumbup:

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

Posted: 22 Apr 2019, 09:17
by joedf
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?

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

Posted: 22 Apr 2019, 12:30
by Nextron
I'm eager to start using InputHook. When using manual hooks, different keyboard layouts and getting shift-characters are a pain. This also makes it more feasible to set up multiple identical hotkeys that all trigger instead of just the first matching conditional.

Has including mouse events crossed your mind?

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

Posted: 23 Apr 2019, 04:16
by lexikos
Helgef wrote:
22 Apr 2019, 06:41
For v2 I think endkeys / matchlists and such would be better suited (or complemented) as arrays, rather than delimited strings.
I intended to implement that for MatchList, but ran out of steam. I figured that it may as well support the current syntax in v1 either way, since the code has to remain for the Input command.

For EndKeys I do not see much benefit in using an array. It is a list of keys, not arbitrary strings. Send syntax is very familiar and Send will certainly not be changed to use an array.

I am not sure if there would be any benefit in removing the Input() function in v2. Most of the code for it is shared with InputHook.

@HotKeyIt Thanks.

@joedf The documentation says there is no implicit fall-through. There is no good reason to split the values into separate case statements if they are all to execute the same code. If you want them on separate lines, you can use continuation lines. If fall-through was permitted in that case, there would be confusion with blank or commented lines (which are generally the same as a non-existent line).

@Nextron Yes.

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

Posted: 23 Apr 2019, 10:27
by joedf
@lexikos Sound goods. In that case, should there be a warning for blank cases? As in it will be interpreted as a blank line and not fall-through.

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

Posted: 23 Apr 2019, 13:47
by Helgef
Hello.

Regarding EndKeys syntax, I do not see any benefit of it being similar to the Send syntax. Rather the contrary in fact, since you cannot have {Key up} as endkey or have !{key} to mean alt + key. Using arrays of key names (such as those described in the key list), would make more sense and be more readable imo. Something to look at,

Code: Select all

EndKeys := "{enter}.{esc}{{}{}}"
EndKeys := ["Enter", ".", "Esc", "{", "}"]
Although the use of { might be rare. For ease of typing, I do give the current syntax the upper hand in a (perhaps also rare) case like this,

Code: Select all

EndKeys := "abcdef"
EndKeys := ["a", "b", "c", "d", "e", "f"]
If endkeys must be a string, a comma separated list would be a better choice imo.
Send will certainly not be changed to use an array.
I am not sure if there would be any benefit in removing the Input() function in v2
Maybe we discuss this another day, somewhere else.
Switch:
@joedf, I thought you were asking if your example was valid syntax for escaping value==1 ending up in default:, it should be, it shouldn't yield a warning.
I think break (or another keyword) to end the switch, it is useful even if fall through isn't possible, although in v2, using goto would be ok.

Cheers.

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

Posted: 24 Apr 2019, 19:42
by lexikos
Helgef wrote:Rather the contrary in [my opinion], since you cannot have {Key up} as endkey or have !{key} to mean alt + key.
So these two lists of keys should have different syntax because the functions using them have different capabilities? What if we want to add this capability down the track? In that case, would we use ["!key", "other_key"], ["!{key}","{other_key}"], or reintroduce Send syntax? The alleged problem can be solved by reserving !#^+ and performing more validation on the key names.
Using arrays of key names (such as those described in the key list), would make more sense and be more readable imo.
imo: For key names, it is not more readable, and makes no more or less sense. {{} and {}} are a bit hard to look at, but so is ["""",",","'"] (I suppose """,'" is only slightly better, and actually, they both looked much worse in the post editor, without the monospace font). With a list of single-character keys other than {/} (like the typical hotstring end chars), a string of characters is more readable, compact and convenient. Even with the braces, Send syntax is more compact. Even if it's a bit more unusual (in general programming) than an array of strings, users likely are - or will become - familiar with Send syntax.

On the other hand, for a string of end characters, it is probably more intuitive to treat them as such, not handle them by VK. I considered adding a separate EndChars property to retrieve or set the string of end characters, but didn't want to further add to the code size (yet) if there wasn't much need for it. Then again, EndKeys can have keys interspersed with end characters when the E option is present, and this complicates the code a little. Removing the E option in v2 and replacing it with an EndChars property might reduce code size. (The Input function could be kept but would not support end characters in that case. Actually, it could be simplified by removing the E option and using {Text} instead, like Send.)

Syntax aside, in my experience, EndKeys is typically a static list. What advantage is there in constructing an array? The actual end keys are marked in two fixed-size arrays which include all key codes, and the list (with the original naming and order) is not kept. You can build an array piecemeal and then pass it to InputHook, but you could just call KeyOpt for each key or group of keys instead.
joedf wrote: In that case, should there be a warning for blank cases?
No, there should not. An empty case is perfectly valid, either as a means of defining an exception to the other cases when they are not mutually exclusive (for switch without a parameter), or when the content of the case happens to be commented out. One should be able to write valid code without being nagged.

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

Posted: 25 Apr 2019, 09:15
by Helgef
So these two lists of keys should have different syntax because the functions using them have different capabilities?
The two list of keys have a completely different meaning, so there is no reason they should share syntax in the first place, but that alone isn't a reason to not share syntax. Endkeys is effectively a list of hotkeys with one common function, hence it makes more sense to use the hotkey syntax, vs., the send syntax. Even with the E option it is still a list of triggers rather than a list of actions.
What if we want to add this capability down the track?
I think ["!key", "other_key"] and also ["key & other_key", "key up"] are very natural choices It works with the E option too, but,
Removing the E option in v2 and replacing it with an EndChars property
sounds like a plan :thumbup:.

["""",",","'"]
It is a good example of improvements made in v2, where I'd write it like this: ['"', ',', "'"]
I suppose """,'" is only slightly better
I think it is worse than ["""",",","'"], i think it is much worse than ['"', ',', "'"], I think '",`'' is perhaps slightly better than ["""",",","'"], without syntax highlighting that is.

Syntax aside, in my experience, EndKeys is typically a static list. What advantage is there in constructing an array?
Typically, constructing the array wouldn't happen very often and not during performance critical conditions. So, syntax aside, I do not think there is any disadvantage in constructing an array. Under that premiss, only syntax matters. However, if you ever need to modify and / or search in the list, working with an array is easier I think (especially if in would work on arrays).
I really do not care much about how (or even if) it is done in v1, for v2 it isn't fantastically important to me either, but I wouldn't add InputHook to v1 at all, and I would replace input with InputHook for v2, and rename it to input.

Cheers.

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

Posted: 25 Apr 2019, 10:20
by jeeswg
- I also think that it makes sense if both EndKeys and MatchList use a similar syntax. Not that I feel especially strongly.

- Suggestions re. ["""", ",", "'"]:
- [A_DQ, A_Comma, A_SQ]
- var `= "|,|'
- obj := ArrPSL(A_DQ "|,|'")
- obj := StrSplit(A_DQ "|,|'", "|")

- When considering Send/hotkey syntax. The Send syntax could be useful (via some means) to define an advanced hotkey/hotstring, e.g. 'ctrl+a, b' or 'ctrl+space, b': ^ab or ^{Space}b.

- @Helgef: At this stage, I'll just say that: perhaps you've never experienced problems relating to compatibility in a programming language.

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

Posted: 25 Apr 2019, 14:03
by JoeWinograd
Hi lexikos,
A quick note to let you know that I tested the switch-case statement on a large set of if-else-if statements in one of my programs. The original code has 27 if-else statements, plus a fall-through else. The replacement 27 case statements and fall-through default worked perfectly! Much cleaner...very nice! Thanks for the enhancement. Regards, Joe

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

Posted: 26 Apr 2019, 06:54
by just me
@lexikos: Who do you think does actuallay need the new flexible keylogger hook function?

OTOH, Switch/Case is a really nice syntax sugar.

Regards,
just me

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

Posted: 27 Apr 2019, 16:27
by lexikos
@just me I think what you are insinuating is that no one needs this, or that functionality that can be used for keylogging is inherently bad. What do you hope to accomplish by asking your question?

InputHook improves the flexibility and reliability of existing capabilities. Among other things, it makes responding to input while it happens easier and more reliable. Anyone who currently uses the Input command (especially in a loop) may benefit from it. It is the result of ideas collected over the years from various scripts or posts, starting with majkinetor's ISense.

Regarding keylogging; InputHook does not make keyloggers easier, more likely, or more of a risk to privacy or security. Keylogging is already extremely simple with Input and a loop. Looping Input can be unreliable for real-time use like auto-complete or emulating hotstrings, but a keylogger can just let the Input command collect input 99% of the time and interrupt it on seldom occasions to update the log or whatever.

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

Posted: 27 Apr 2019, 18:13
by swagfag
im sure the evil macbook mafia will find some use for it lol
and i. ive used it to replace, now with just a few lines of code, 4k hotkey combinations, which was actually a feature i requested for a script last summer(granted theyre being generated programmatically but still)
looking forward to 1.1.31 or whatever its v2 counterpart is gonna be

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

Posted: 28 Apr 2019, 10:03
by jmeneses
Many thanks @lexikos for your exceptional job
@just me it is very easy to criticize a written page because you do not write it your ready your alias says it all
Written from my mobile

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

Posted: 29 Apr 2019, 08:54
by just me
@lexikos: I already abandoned to hope that v2 will be released in the foreseeable future. So I look at the changes for v1, and sometimes I'm wondering why you think that the changes in v1 are more important than v2 developement.
And every change which might make keylogging easier for some AHK users might also cause those nasty AV companies to punish the AHK scripting language again. These 'false positives' are very exhilarating if you are responsible for some AHK scripts running in the office environment.

Just my two cents!

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

Posted: 29 Apr 2019, 09:49
by Flipeador
I like this!. I wonder if swich-case has any other advantage besides being more visually pleasing (or syntax sugar) than if-else; Like, for example, better performance (I like it anyway :P).
@just me I think all that was discussed in other topics.
Spoiler

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

Posted: 30 Apr 2019, 07:39
by lexikos
just me wrote:And every change which might make keylogging easier [...]
I wrote:InputHook does not make keyloggers easier

just me wrote:[...] sometimes I'm wondering why you think that the changes in v1 are more important than v2 developement.
Perhaps you have forgotten this:
just me wrote:
29 Apr 2017, 09:50
Besides inevitable [bug] fixes you should restrict your activities to v2.
lexikos wrote:
29 Apr 2017, 19:18
It was my intention to drop all work on v1 several years ago, but lack of progress with v2 (and occasional unrelated ideas) changed that. Anyway, my interests range outside of what's strictly relevant to the v2 project. Restricting what I work on based on any criteria other than what takes my interest generally only serves to kill my motivation. Ultimately, whether or how much I develop my ideas for v1 will hinge on how much it takes my interest, not how much I try to dedicate my time to one or the other.
Also, InputHook is not "v1 development". It is "v1 and future versions development", and may impact the syntax or continuance of the Input function. I developed it in the v1 branch first as a favour to the large number of v1 users, since it was trivial to do so.

Also, working on InputHook has been motivational. I think I have spent more time working on v2 in the last 3 days than in the previous 5 months.