AutoHotkey Community

I think it is up to the coder to learn what it at hand. There is always improvements to be made and it seems Chris is more than willing to get suggestions and make improvements. Since he is so willing, as I learn of inconsistencies or errors I plan to tell him. In my limited experience so far I have been able to accomplish everything I have needed. (limited remember)

Coming from AU3 I can only compare and say "I wish it was like this or that". Instead what I have done is found new ways to accomplish the same thing. Some things have turned out way less complicated than AU3, some are the same and some require more coding. Like a ping command (I started a thread under the wish list for ping. In the mean time I have found a 7 line work around for not having a ping command within AHK.) I think it is a toss up in the few scripts I have ported over from AU3 to AHK.

That is my opinion and my limited experience. I say don't make it complicated. But if you can give us the same function in 1 line of code instead of 5 or 10 lines, do it! I am willing to learn what I need to learn to accomplish my scripting goals! To me that is what I enjoy about programming/scripting!

AutoHotKey should keep it simple. There are already lots of complex, confusing, convoluted, bizzare, and backwards looking programming languages out there. Why add to it? There is already machine code, assembly, C, C++, Fortran, etc... I think making a complex programming language that is hard to use, can be easily done, but how many can make it simple? Simple, is what is actually hard to do.

When a new function is added than care should be take to make it easy to use. Something Chris is doing a good job at.

What is needed is to go in the other direction and for people to design simple, easy to use, and easy to understand programming languages.

AutoHotKey is right "there" and is even easier to use than Basic/Visual Basic. Why mess up a good thing? What is simpler to use than AHK, but has as much power?

If anything, I think AHK needs to "clean up" on its user tools and make those more "user friendly" and "sophisticated". What, in my opinion, AutoHotKey needs is its own Editor (AHKEditor and AHKStudio are coming long, but still have far to go), a better AU3Recorder (well its own TRUE AHKrecorder w/ Control Clicks...), etc... Even the great program AHK SmartGUI, could add some loving touches to its awesome self.

To me, by AHK being a more practical, useful, and a simpler language, it will blow away its competition "over the long run".

I've split off the posts that used to be here into a new topic, as well as adding a new reply. This was done to give the topic a better subject line, which will hopefully be noticed by more people and thus attract more comments.

Here's the new topic: Establishing a standard/recommended editor for AutoHotkey

There have been a lot of posts on this subject and I just caught up on all of them so I'll try to keep mine short.

I've been with AHK very close to the beginning. My background started with batch jobs, simple HTML, and then AutoIt 2. I was eagerly waiting for version 3 to come out for new enhancements...until I saw the first beta, way to complex for me.

Luckily I stumbled upon AHK while it was still in beta, it was everything I had hoped for out of the AutoIt 3 update, and more.

I agree with the simple commands, but at the same time can't think of a better way to handle ListViews. I have built up my knowledge with expressions and think they are a great addition, but they aren't needed with AHK, you can use simple GoSub command and just set temporary variables before hand. So I also agree with the complex commands.

With dealing with trying to get Chris to add new features, he has the general user in mind, and always has. I have asked him for complex stuff that I might be the only user that wants it, and he has time and time again remind me that I can do the same stuff with simple commands, just more code. And unless the majority of users want that, he won't do it. Since there always seems a work around. He is also open to polls, and has even asked users what the syntax should be sometimes before he releases new features.

AHK has come a long way, and in my opinion has stayed true where it can to a simple syntax. Gui's have been listed as an example of complex syntax when in reality it still holds true to the Command, option, option style.

Thanks Chris for all your *free* work on AHK, and keep the new features coming.

thanks,
beardboy

Thanks for your comments above.

On a related note, I haven't forgotten requests for things like a service manipulation command. However, the advent of DllCall makes me lean more toward adding seldom-used features as includable files. Someday, I hope to have these files organized into a standard library distributed with the program. It might work something like:

#include <services.ahk>
...
ServiceStart("NameOfService") ; Use a function defined in the above file.

Examples such as the above involve me or someone researching how to call the API to do it, which in a large part explains the procrastination and delay.

Thanks for continuing to stand behind the project in spite of its lack of progress in areas like these.

I've seen examples in the help files which contain lines such as:



If there was a way to have a more friendly way of applying words instead of codes like 0x40000000, perhaps through an include file or something, that would be nice.

I have no idea where to find these types of codes.
________
Toyota tf104

It's a good question. Although I think there are far too many constants to put into a single file (many thousands), certainly specific #Include files could contain a small set of constants relevant to the API they expose to the script.

One problem with this idea is that such a file would have to be #include'd at the top of the script for auto-execute section to define the constants. But perhaps a #define directive could be added that creates constants at load-time regardless of how far down they exist in the script.

Don't know if this is directly applicable, but MS supplies constant files such as

<!--
METADATA
TYPE="TypeLib"
NAME="Microsoft ActiveX Data Objects 2.5 Library"
UUID="{00000205-0000-0010-8000-00AA006D2EA4}"
VERSION="2.5"
-->

these look like :

<%
'--------------------------------------------------------------------
' Microsoft ADO
'
' (c) 1996 Microsoft Corporation. All Rights Reserved.

' ADO constants include file for VBScript
'
'--------------------------------------------------------------------

'---- CursorTypeEnum Values ----
Const adOpenForwardOnly = 0
Const adOpenKeyset = 1
Const adOpenDynamic = 2
Const adOpenStatic = 3

'---- CursorOptionEnum Values ----
Const adHoldRecords = &H00000100
Const adMovePrevious = &H00000200
Const adAddNew = &H01000400
Const adDelete = &H01000800
Const adUpdate = &H01008000
Const adBookmark = &H00002000
Const adApproxPosition = &H00004000
Const adUpdateBatch = &H00010000
Const adResync = &H00020000

......

perhaps these could be referenced by AHK ?
________
Drug Test

I think you would need the API headers themselves (such as windows.h), which I don't think come standard with the OS.