10 replies to this topic

[mrkafk]

Hello everyone,

Newbies like me stumble upon issue like Send sending input too fast in some contexts, like Remote Desktop, see here for example: <!-- l --><a class="postlink-local" href="http://www.autohotkey.com/community/viewtopic.php?f=1&t=92896">viewtopic.php?f=1&t=92896</a><!-- l -->

I found experimentally that SetKeyDelay 3 was enough to make hotstrings work properly over RDP session in LAN (or maybe RDP client chokes on keys being sent too fast to it?).

It might be nice to add default SetKeyDelay, with value like 5, to default (installed) AHK script, with commend on using it over RDP, commented out or not - just "heads up" on this issue for new users.

[Leef_me]

You are the newbie and your suggestion shows you have not carefully read the documentation. You are the new user who needs the "heads up" on this issue.

Please, read (at least) these sections:
<!-- m -->http://www.autohotke...SetKeyDelay.htm<!-- m -->
Every newly launched thread (such as a hotkey, custom menu item, or timed subroutine) starts off fresh with the default setting for this command. That default may be changed by using this command in the auto-execute section (top part of the script).

<!-- m -->http://www.autohotke...cripts.htm#auto<!-- m -->

[mrkafk]

You are the newbie and your suggestion shows you have not carefully read the documentation. You are the new user who needs the "heads up" on this issue.

It shows you have not carefully read this article:

http://www.joelonsof...0000000062.html

I have no intention to read documentation as anything but the last resort. I don't need to read the documentation to use my mobile phone or configure the wifi router or use Windows and especially to use Mac - I should not need to read documentation to use AHK either.

The software is flawed to the extent its users need to read any documentation at all. The more users need to read the documentation, the worse and more incorrect is behavior of the software. If today were 1960s when computers were scarce and human time was cheap, expecting users to read the documentation would have been reasonable. But those are not 1960s, and it's machine time that is cheap and human time that is scarce now. So make software work right out of box and don't expect users to read the documentation (as if 99% of them just didn't go away on the very suggestion and dropped the use of particular piece of software and switched to something else that didn't require them to read docs).

Please, read (at least) these sections:
<!-- m -->http://www.autohotke...SetKeyDelay.htm<!-- m -->
Every newly launched thread (such as a hotkey, custom menu item, or timed subroutine) starts off fresh with the default setting for this command. That default may be changed by using this command in the auto-execute section (top part of the script).

<!-- m -->http://www.autohotke...cripts.htm#auto<!-- m -->

I have put SetKeyDelay precisely at the top of the script before and on retesting it now over remote desktop it actually doesn't work much of the time - I must have got the correct result by accident before. Even setting SetKeyDelay 30 in autoexecute section doesn't help.

[geekdude]

Do you really think that you shouldn't have to read about a programming language's syntax before you can become fluent? Asking for help is just as bad as reading the docs, IMO, if you think you should not have to read any docs to be able to code.

[engunneer]

while that is a good article for UI design, it can't really apply to a programing language. AHK has one of the better help files I have seen for programming languages (It's a start that it even has one). It's certainly not perfect, but it has useful examples, and explains every option for every command.

Personally, I'd lean more to the "I shouldn't have to post in a forum to get this working" side, but I think our forum is pretty good too.

[mrkafk]

Do you really think that you shouldn't have to read about a programming language's syntax before you can become fluent? Asking for help is just as bad as reading the docs, IMO, if you think you should not have to read any docs to be able to code.

1. Strictly speaking, AHK is not a programming language - it's a utility that happens to have a programming language. Ideally, using it should:

a. not require writing any code
b. defaults should work in such way as user never has to tweak them


2. In my work I had to learn from some to most of (chronologically): C, AWK, Perl, C++, Python, Java, Python, C#.

How much more do I have to learn to be able to effectively work with software? Are we supposed to spend our lives read docs on obscure programming language to get some work done?

I appreciate the work that people are doing with AHK, but frankly, the programming language in AHK is obscure at best. It is broadly an imperative language, so why does it not have typical C/Java-like syntax and operators and general ideas behind the design?

What's the purpose behind reinventing the wheel (say, with arrays, or variable expansion)? Python doesn't: it doesn't try to change what can't be improved, it takes what has worked and in those respects (loops, functions, arrays) it works it has always worked and the way user expect it (minus some minor stuff like O(n) complexity of removing element from the list counting from the tail, but it's not a problem most of the time). The result is superb. I wish AHK had built-in Python with its own specific extension!

[mrkafk]

while that is a good article for UI design, it can't really apply to a programing language. AHK has one of the better help files I have seen for programming languages (It's a start that it even has one). It's certainly not perfect, but it has useful examples, and explains every option for every command.

Personally, I'd lean more to the "I shouldn't have to post in a forum to get this working" side, but I think our forum is pretty good too.

The ideal: the very fact that user X has to pester anyone with Y on forum OR read documentation indicates software should be changed in such way that this thing doesn't happen.

Apart from actual bugs, you don't have *many* people posting anywhere what to do with Chrome or even FF.

Yes, I know that AHK is sort of border case since it sort of "programs" windows (even though e.g. hotstrings are not strictly programming, more like configuration). I do feel like I'm asking for too much but I expect OSS to rise to usability levels of the best commercial software. AHK is good but not that good, to be frank.

What puzzles me why AHK doesn't use Python OR another programming language that proved its worth. Say, Mono/C#. What's the reason behind this specific array handling for instance? Why single = in conditionals? If you use braces, why not follow standard parentheses C/Java-like notation?

if (something)
{
}

It should be either Python's way:

if something:
do_this

or C/Java:

if (something)
{
do_something
}

..not something in between.

And so on and on.

[MasterFocus]

1. Strictly speaking, AHK is not a programming language - it's a utility that happens to have a programming language. Ideally, using it should:

a. not require writing any code
b. defaults should work in such way as user never has to tweak them

I suppose we won't convince you it doesn't work like that.
In that case, AHK's source code is available, so feel free to have a look at it and sugest where/how these changes should be implemented.
(<!-- m -->https://github.com/L...os/AutoHotkey_L<!-- m -->)

[engunneer]

scripting language ... not require writing any code ... scripting language :?: :!: :?: :!:

[zoraxe]

You are the newbie and your suggestion shows you have not carefully read the documentation. You are the new user who needs the "heads up" on this issue.

It shows you have not carefully read this article:

http://www.joelonsof...0000000062.html

I have no intention to read documentation as anything but the last resort. I don't need to read the documentation to use my mobile phone or configure the wifi router or use Windows and especially to use Mac - I should not need to read documentation to use AHK either.

The software is flawed to the extent its users need to read any documentation at all. The more users need to read the documentation, the worse and more incorrect is behavior of the software. If today were 1960s when computers were scarce and human time was cheap, expecting users to read the documentation would have been reasonable. But those are not 1960s, and it's machine time that is cheap and human time that is scarce now. So make software work right out of box and don't expect users to read the documentation (as if 99% of them just didn't go away on the very suggestion and dropped the use of particular piece of software and switched to something else that didn't require them to read docs).

Please, read (at least) these sections:
<!-- m -->http://www.autohotke...SetKeyDelay.htm<!-- m -->
Every newly launched thread (such as a hotkey, custom menu item, or timed subroutine) starts off fresh with the default setting for this command. That default may be changed by using this command in the auto-execute section (top part of the script).

<!-- m -->http://www.autohotke...cripts.htm#auto<!-- m -->

I have put SetKeyDelay precisely at the top of the script before and on retesting it now over remote desktop it actually doesn't work much of the time - I must have got the correct result by accident before. Even setting SetKeyDelay 30 in autoexecute section doesn't help.

Using a stove is fairly simple, but that doesn't make me a cook.
Using a brush is fairly simple, but that doesn't make me a painter.
Running an AHK script is fairly simple, but that doesn't make you an AHK programmer...