AutoHotkey Community

`
Intention : to fully understand AHK as a tool, including its "lineage" & RELATIONSHIPS
to the other objects-components-languages it interacts with ;

... such that I can most effectively invest my time in studying these areas
in a way that will bring me to the highest competencies as quickly as possible.

***********************************************

The most efficient way for me to quickly earn high level competency
is to 1st have a global view & feel for the inter-RELATIONSHIPS of the topic I'm studying.

As a beginner here, I have acquired multiple books on the Windows shell,
& some video tutorials by folks such as Mark Russinovich, etc. (though haven't yet read/viewed many of them).

I'd greatly appreciate it if someone would provide an explanation of 'HOW' AHK relates to,
depends on, works with/against:

Win32 API, COM, MFC, WSH, WMI, etc. etc.

Truthfully, I'm just throwing up every concept-acronym I can think of,
& I don't know if they relate or not (because I don't understand them ... yet),
but hopefully I have demonstrated the intention of my quest.

As best as I've been able to read on the forum and in Help,
AHK itself is written in C++ ?

So this in itself determines what it can/can't do or has a(n) easy/difficult time doing ?

I see some strings used in various scripts that I can't find in Help,
and I assume they must be a part of the API or some COM object, etc.,
& it seems like the better I understand those arenas,
the more skilfully I'll be able to employ AHK.

It does impress me that some long-time posters here,
who are obviously veteran developers that have 'been there & done it ... all' ,
use AHK because it's :

* Powerful
* Light on system resources
* Fast !!

So as I like to model successful pracititioners in any field,
I ask you to kindly share your points of view here in a sort of "History/Philosophy" lesson,
and Thank You for your time & energy.
.

i'll give you short answer. AHK is written in C++. basically it's huge wrapper of Win32 API. simplified as much as possible.

Look at MsgBox (AHK Command)
and MessageBoxEx (Win32 API)

then compare

Perfect ! & Thanks ..... this is EXACTLY the kind of pointer/hint I'm looking for

but i did not mean that AHK is just full of Win32 API wrappers. AHK also invented smart iterator called Loop and more

~hopefully I'll soon understand what a Loop iterator is

... man, this is getting to be ALMOST as fun as dropping in to a perfect glassy tube/powder chute
or sinking a 40' for an Eagle

Hey geor, you've provided an excellent base for my own inquiry - maybe we can learn something together here.

I'm not new to coding at all, I've been doing this for about 30 years now and still going strong. To sum it up, I've learned and disposed of about 20 languages and I've written a lot of protocols and interfaces between software/hardware components. While I can read C and assembler and have done some work with both, I've specifically avoided them because I don't personally believe my time is well spent at that level when there are so many higher-level languages around - I can twiddle, I just choose not to. Right now I'm on the fast track to getting intense with PHP (to use along with about six other language/stack/technologies that I use on a daily basis), so I have to decide carefully how much time I can afford to spend on AHK as well.

When I think of PHP, BASIC, C#, Java, or any related variants, I know we can do anything we want with the Win32 API, COM, Managed code, and any libraries or protocols built over these tools. You do need to know something about the mechanics of the tools (and related data typing) in order to use them competently.

Using AHK does not require any knowledge of C or details about the Win32 API. However, this simplicity needs to be weighed against other factors. I see AHK as coming from a single source, with unusual syntax, and pretty much the same functionality that we can get with any other tool. Does it balance? Not yet, I have to look at the unique features to see if they're compelling enough to justify dedicating some time.

The unique features in AHK include fast access to the keyboard, and excellent handling of the mouse and Windows objects. Aside from that, virtually all of the functionality seems to be a syntax-specific wrapper around features readily available elsewhere. I'm being generous because "AutoHotKey" seems to have started as a keylogger, which it did/does really well, and everything else after that is just a wrapper around existing functionality.

No, I'm not dis-ing the software. I have a lot of respect for what I see here. The world is full of great "wrappers" and great people who crete them. Wrappers abstract complexities and make them look easy, and that's good for everyone. I'm just saying this isn't new and all powerful like some of our friends here seem to think - and it's not the only game in town. Again, the information is out there for anyone who cares to do their reading. It actually took me months to figure out what people were getting so excited about here. It's a key logger, it clicks stuff on the screen for you, OK... Then it does networking and GUI, and takes out the trash and watches the dog and ... well, maybe not that far, but I had a hard time "getting it" until I realized that everything is just a wrapper around something else that I've already done.

Regarding Win32, COM, etc, these are all documented extremely well. You can make use of the Win32 API and any COM component from WSH, VBA, or just about any other scripting or compiled language. I think it's worth it to get to know AHK for what it does well, and just acknowledge for now that it happens to do other things too - you probably don't need to confuse these things with AHK when just getting started.

So, I would also like to find a small series of intense tutorials (yes, I found "the one" and it's a good one) to put me on the fast track to getting productive with AHK. I've already spent many nights struggling with global vs local behaviors, getting clicks and keypresses to work just right, making sure I got my back-ticks and := operators right, etc. I'm guessing geor could use something similar. What I could really use is a series of walk-throughs that exercise the few things that AHK does uniquely well, like complex keyboard mapping and targeting objects on the Window for clicks and keypresses. After that, using AHK seems to be a matter of learning how other API's work and then figuring out how to use those with AHK syntax - when code samples are readily available in other languages.

OK, I've gotten myself into enough trouble for one posting. Flame jacket on. Lemme have it!

I have a few comments, but not enough time to write a tutorial (sorry)

The real power of AHK (IMHO) lies with the commands with names starting with Control. These commands make getting your clicks and keypresses "just so" a thing of the past. ControlClick, as an example can basically be used as a "Click on the button that says n" command, with the benefit that it doesn't take over the mouse. It just tells the control to act like it's been clicked. Since this even works on minimized windows, you can do some pretty powerful automation tasks without actually interfering with your normal computer operation.

The second major thing is the simplicity of Gui commands (though you can certainly make them more complex). I have a GUI script at work that sucks information out of our call center database, lists it on the screen in a LV, highlights any calls that belong to the user (autodetects who you are) and has visual indicators for management to see the backlog in the call center. This app runs on about a dozen computers, and replaces an HTML interface that was limited to only 10 listings per page, didn't auto refresh, had no indicator of how far behind we were in calls, and didn't tell you when you had a call specifically for you. Granted, if IT had a bunch of time, they could have fixed the html interface, but that hasn't happened yet two years on. I have some other GUI scripts that I have worked on, but my call center app is the most complex so far.

For me as a non-programmer (or non-programmer enough that I'm not getting paid for code), AHK works as a general purpose programming language. I know I could use other languages for the things I do, but AHK does what I need it to in a way I understand.

Thanks for your well though out comments.

_________________

(Common Answers) - New Tutorials Forum - Humongous FAQ

i've seen many people here complained about the Syntax. i'd like to remind people that you must realize that if it has 'usual' syntax. this simplicity and convenience couldn't be done. the biggest power of ahk is it's ease of use than ANY language out there. which gives you gentle learning curve and the productivity. or rather the syntax isn't that unusual actually. except commands operators and blocks are came from the C language which is 99% same (except modulo). thus 'unusual syntax' is just meaning of how ahk simplified typical windowing tasks. ahk's expression, the base of language isn't unusual. you'll see how expert people uses ahk like other languages.

Thanks, y'all - I was hoping my inquiry hadn't died,

'cause I've eaten but I'm still not full
(want more information & guidance & help ..... )

I benefit from what everyone just said !
but especially 'preciate Starbuck taking that time -
the concept of "wrapper" will prove a good one
for me to wrap my brain around.

I'm an "intelligent beginner" ? -
circling back to read Matt Pietrek & Petzold, et. al.,
to get some knowledge about API, COM, etc.

And the fact that it is so easy for a rank beginner
to get some immediate success with -
I estimate to have already saved 1 day/week for several weeks now -
getting more done in the same time,
as well as leaving more time to play w/ family & friends

I'd like to be a one to write (yet another) beginner's tutorial down the road -
and it will be task/project based.

In my experience as a teacher in several unrelated fields,
I set up practical projects that were of benefit to the :

"So What? What's in it for ME ?" attitude.

& even if those weren't something absolutely unforgettable to the student,
I made sure that they formed enough inferences from it,
that they COULD create Exactly what they wanted
due to their experience from our classes.


I see this same metaphor with so darn many things in I.T./C.S. -

file mgr/explorers for instance -

a beginner just doesn't know the questions to ask,
as to why/how xplorer2 or DOpus or TC or ...... (insert fav.)
could literally save them perhaps 1/2 - 1 hr for every 8 hours on the computer - IMMEDIATELY !!

So, same w/ AHK - I "got it" about the hotkeys & hotstrings,
but don't yet really have the "aHA!" about the rest of the stuff AHK
can help me do.

but i will ;)
.

About syntax, I hope I can cite examples of why I have issues with it, but without nitpicking on specifics. Let me say one more time but differently - I don't care about specific syntax issues, my overall sentiment is based on the idea that the language is full of this sort of syntactical uniqueness.

Example1:My issues with that functional code that I just wrote include the following:

• CurrentWindowText does not require %signs but %DelayTime% does, even though it's not being used in a calculation. Since DelayTime is in a position that requires a numeric, the string can't be anything other than a variable reference.
• The backticks are required before the commas inside the function. I have parens to highlight the expression, that should be enough. The FAQ says "Literal commas must also be escaped (`,) except when used in MsgBox or the last parameter of any command (in which case the accent is permitted but not necessary)." But this is not the case because removing the ticks results in the expression not rendering.
• The % sign alone, used to set off an expression, is highly unusual.

Here's another example from the same area:

• Here we see that quotes are not required for the first statement but the quotes Must be on the second. Perhaps this is a bug? If so, every software has bugs and I will gladly strike this off my short list for this purpose.

The := syntax to denote expressions is a good example of what the most recent Guest cited as being syntax required to make the language simple to use. But how many errors does everyone make when not properly deciding between "=" and ":="? What about "Success := true"? Since true is a reserved word there should be no need for ":=". If I'm not mistaken, we can indeed use "Success = true", but might that be confused with ' Success = "true" '? The convenience of not requiring quotes now provokes a lot more thinking - and for new developers who have never used a programming language, that sort of depth should not be required - and it is not required in languages like BASIC which are specifically designed for new programmers. If the convenience when it works introduces more inconvenience because we need to understand the nuances of how to make things convenient, then a question arises as to whether the syntax is more help or burden. In tht last example, I might instinctively have wanted to try if SubStr(...):="text", thinking that one side of the equation is an expression so why not?

The notation for hotkeys is also unusual, but so is the functionality, so I have no problem with it. For example: "#w::" remaps the Win+w key. Great. I would maintain that this is the only reason for a language to have radically unusual syntax.

Here's a small one: no for/next loop, no do/while? Just Loop? OK, there's only one construct to remember, but I believe these constructs are standard in all languages these days.

Also consider IfWinExist, IfWinActive, and similar statements compared to the WinExist() and WinActive() functions. It's great that developers have the freedom to chose between statements and functions, but I think some emphasis should be placed on new developers using one format or the other, just to get them started, and then later they can make use of the other format when they see code that uses it. If you want to keep the language simple for beginners then make a distinction between "first class" / preferred syntax and secondary, not so preferred syntax. Who is to decide? That's another discussion. The point is that the language can be made even more simple if a lot of these duplicate features were moved to a secondary help index - "use this stuff after you've learned the rest".

Finally and related, what about #IfWinActive and related statements. They're styled like an #include directive, prefixed like a Win keystroke, and they include implied conditional behavior. Was any of that necessary? This is another entire class of commands that would be in my list of "don't bother with this until later" notes for newcomers.

I'm not complaining about the language per-se, I'm just saying it's sufficiently different and inconsistent to warrant a "is this really worth it" question when comparing it to other languages.

Note that despite the issues I present, I know enough about the software to be able to cite the issue - so I'm far from giving up on it. I actually do like it.

@engunneer: Thanks for the reference to Control statements - I didn't have a clue!

One of my big issues now is that I open a window and I have to be very careful to make sure I am where I think I am before clicking and keying. My code has a lot of error handling in case keys are dropped (which happens) or clicks are made where they should have occurred.

About your own code at work. On one hand I think it's great that you've been able to make strides in the absence of better support from your IT staff. On the other hand, that's a management issue, not technical, and if you can't get your job done then management needs to make decisions about it. By getting around the problem you're enabling IT to do a poor job, keeping management in the dark about internal problems, etc. On top of that, when you're gone who will maintain your code? Someone is going to get stuck looking at your code without a clue, that person may not be in IT because IT may not even be aware of your code. That whole situation is just "wrong" from many business perspectives. Sure, you have a job to do and you can put a feather in your cap for showing how you can get around issues. But that's not the way business should work. Quick fixes like that are not good long-term solutions - if you have other issues with IT, you could thank yourself in part for not pressing them to fix the other issues that you fixed yourself.

Thanks for your help here and in so many other postings.

this thread is growing exponentially, as I have quite a few comments about your last two posts. I'll try to answer a many as I can remember.

Re: work, I actually had support from IT in setting up the stored procedure for me to call, and they have a copy of all source code (and have had it for over a year). Granted, I don't expect them to maintain it. We are in the middle of a huge IT investment (we've more than tripled staff and are replacing every single workstation and IT infrastructure component) that will make my program obsolete. My work was mainly a bridge between the crappy system the last consultant built for us, and the much more usable system IT is piloting and actively working on now. I fully expect my code to be dead in another year, but dealing with a bad system for 2+ years while they finally do it right this time was unbearable. I know it takes time to build it right, and that's what they are doing. Also, we've just refreshed alot of management too, and I am much more confident about the new guys doing things right. My job there is actually to work on standardizing systems and making them more robust.

Re: being sure you are clicking where you expect. This should easily be eliminated via Control* commands. Also see WinMenuSelectItem

Re: Example 1

works just fine for me. I'm actually surprised that escaping those commas worked, but now see that they would. As far as single % syntax, I agree that it is a bit odd. It makes since if you've been with AHK for a long time. Basically, AHK is forked from AutoIt2, with a bunch of stuff added in. AutoIt, IIRC, only allowed strings as parameters, and you could use %% around variables. As a general thing, Chris added the ability to use an expression for ANY parameter of any command. This is actually very powerful. This also allows simple double dereferencing for those situations where it will save a line of code or where you need that sort of thing. Also note that there is a difference between a Commands and Statements. Statements are any thing in expression form

Commands are anything else (MsgBox, Gui, WinWait, etc)
Over time, AHK has been transitioning from commands to statements. It is expected that v2 (if it ever arrives) will be mostly statement based. There is also a wrapper you can download to make basically every command in AHK available as a statement, so you can write all the statement based code you want.

Re: Example 2
I think you are mistaken on the first line, unless you intend to use opposite logic. take for example:

You get msgbox 1 and 4. In the case of msgbox 1,
SubStr(CurrentWindowText,1,7) is "The Hea", The is "", so the comparison is false, so the not makes it true.
for msgbox 3, SubStr(CurrentWindowText,1,7) is "The Hea", the right side is "The Header", so the comparison is false
For a detailed examination of when expressions need % and how someone can reach the wrong conclusions about the need for "" and %%, see This thread

Re: := syntax: Agreed, := is sort of glommed on to the language. It has some precedent, but does cause alot of confusion. As one of the top posters in the forum (mainly helping people out), I see this is certainly a common point of confusion. There are alot of people using = instead of :=. I use both, depending on circumstances. If you keep to := all the time for assignment and = all the time for comparison, then confusion should be minimal. I don't want to disable = as assignment, though since many new programmers may not expect to have to put "" around strings when using :=

Re: While and For Loops : see Autohokey_L. I find that not having While is not an incredible lacking. I think it would confuse new programmers, though I do want them in the language. Agree that it's a small thing, but would be nice.

Re: IfWinActive vs. If WinActive()
See http://www.autohotkey.com/forum/viewtopic.php?t=34040 , where I actually propose marking many of these commands as deprecated, so as you say:


Re: #IfWinActive, etc.: I agree that the statements are confusing compared to the non directive version. It also confuses many that they can't take variables, but they can take window groups, which have variable window in them. starting with # overloads # a little, but # as a hotkey prefix and # as a directive mark are distinct enough to not confuse, I think. They are supposed to imply conditional behavior, since they do make the hotkeys conditional. Agree that a beginner vs advanced help file could reduce confusion up front, but long term is a bad idea. Why have someone get all up and trained in the beginner file, then all of a sudden turn them back into a newbie when they need an advanced function. The hosted help file does highlight some of the more useful commands in a large font to draw the attention of someone skimming the help page while learning.

I probably had more to say, but this is long enough as it is. And it's late.

I think this is an excellent discussion and everyone so far has many good points.

_________________

(Common Answers) - New Tutorials Forum - Humongous FAQ

Agreed. I'm very pleased that you're taking each point as it comes and presenting a good response for agreement or disagreement. It's a good education. I'm not seeking agreement, just citing observations for people to chew on for themselves. You apparently get that and I really appreciate it.

Hey geor - do you have any specific areas that you'd like to focus on? Maybe we can create a new thread for specific topics of interest. If you're just looking to get on the fast track I'll propose a sort of Summer of Code challenge to AHK coders:

• Let's create a single thread.
• Each response teaches a very specific topic - limited to a general guideline of less than 20 functional lines.
• If you have more in there then you're not focused enough on a specific point, so don't post.
• Comments are encouraged and are not included in the line count.
• Variations are encouraged, duplications are discouraged and should be deleted.
• The subject of every response will be a brief note of exactly what is being profiled. Obviously the subject field is short and this just encourages them to be very brief. Again, if you can't say what you're doing briefly then you need to re-think what you're trying to demonstrate.

If you guys like the idea, let's talk about it a little here and I'll kick it off with a few examples.

@Starbuck - Thank you very much for circling back & considering my potential needs ...
and your bullet-points echo my own sentiments, I believe ....

Here's my grand-poobah philosophical/positional statement -

#1: I'm grateful to Chris, et.al. (including the AutoIT folks) for creating this approach;
& while I wish they had both the time & the inclination to create a Teaching Method,
a pedagogical teaching approach w/ lesson plans that spanned from Beginner to Advanced,
I understand the realities of why that most often does Not happen.

#2: The Help & Documentation seem to me to be exceptionally thorough,
yet presented in (to my observation) more of a standard, what I call, "Noun-Object" format :

"This is this, This is this, That is that, etc. etc. ...... Best of Luck!"

vs. what I call a

"Verb-Relationship" style that explains :

" "This is this, This is this, That is that, etc. etc." .... but WAIT ! there's MORE !! ...

... Here's How/Why they inter-relate, & MOST importantly:
here's Why/How it matters; Why you should care; & What you can begin to do with it."


... step by step, yes, hold my hand even, dadgummit !!
I'm not too proud/too already-an-expert/too ... WHATEVER!?! to admit it, or ask for it !


What I'm proposing or would love to see, is really a multi-level documentation,
because certainly .....
skilled I.T. professionals need only the briefest of guides that they can quickly peruse & then be on their way.
I respect that, & I'll be such a one sooner than later !


#3: Never go past a word or phrase you don't understand,

Sooo ... a method must be presented to cultivate & grow that understanding
through appropriate drills/exercises so as to rapidly come to "Own" the material -
& hopefully such exercises are crafted with an understanding
of the 3 main modalities of perceptual learning - Visual, Auditory, Kinesthetic.


I'll reiterate ... a beginner simply does not even know the appropriate questions to ask ...
a beginner doesn't even know what they don't know !
Or,
Why they should care ?!?

"What's in I.T. for me?"

Therefore, someone who has the time & empathy for the Beginner's Mind COULD relate to it thusly,
& the measure of success COULD be :

"How quickly, and how often, have I as a teacher-coach-guide,
produced (taught/coached/guided) others who approach, duplicate,
or ...
(G*d forbid!)
even Exceed! my own levels of Mastery?"

For myself as an advanced guitarist-Musician & teacher,
I dazzle students w/ a pyrotechnic display of fretboard frenzy,
only enough to capture & hook their attention
so that they're willing to cultivate the necessary discipline,
to do the necessary homework,
that leads to the actualization-attainment of the goal(s).

Meanwhile, YouTube is littered w/ 30 second "How-to-do-I.T." demos by hormonally-driven wunderkindz,
executed @ the equivalent of a hyperPresto 208 beats/minute
that would shame the likes of Yngwie Malmsteen/Hendrix/Vaughan/(u-pick) ....

.... "I saw/heard what you just did, but I don't understand a thing you just said."

.... same applies to scripting-coding, etc. ....

{ peaceout }

Speaking as a fellow/former musician, anyone who mentions Yngvie in a forum posting is top-notch in my book.

Speaking of books - I think your position can be summed up quickly. The docs are exceptional, but the doc here is a reference manual. Full stop. You want a tutorial. The approach to these types of docs is completely different. Tutorials are progressive in order of concepts and increasing complexity, reference docs are sorted alphabetically, and maybe categorized if you're lucky.

To facilitate getting what you/we want in a format that does some good, I propose we start to flesh out the tutorial section of the wiki. Someone who knows more about the software (I guess I can do this now) can create a skeleton of topics for others to fill in the blanks. When done, the result should be an organized document that someone can walk through from start to finish to get an education. I'll take a look at kicking this off within the next week or so.