Forum Posts Feed
Autohotkey vs. AutoIt
< Next Topic | Back to topic list | Previous Topic >
Posted by Fredy
Sep 5, 2012 at 11:24 AM
Edit: Thus, the irony is: Many people discuss the “the web never forgets” phenomenon, whilst in its day to day use, the real problem is not unwanted storage beyond your original intention, but that info, help, etc. given here and today, will be “lost” tomorrow, needing the same info being reformulated again and again, instead of a global attack on this much evident access contradiction: It’s all there, but since they all solely rely on “searching”, you won’t find it anymore (with reasonable “cost”), so it’s produced anew and anew. Of course, there had been strivings to attack this, at least in big-scope fields. Yahoo’s cataloging things, anyone? Cannot be automatted enough, is too expensive, is hence done with. Today’s “overview” / “comparison” sites are mostly conceiled advertising, i.e. they push select offerings which pay for that, if the sites don’t secretely belong to that manufacturer wanting to push his product to begin with.
And again, it’s not a question of “it’s free, hence we can’t expert the effort” - first, all the effort is given, bad very badly applied, it’s squandered for a very good part; second, what would be 100 bucks a year, or say 75, for real good, useful things you’d have easy access to? Always remember the tco, which nowadays can be immense, for many such “free” or ostensible “cheap” offerings.
In our times, much “secretarial work” isn’t done anymore where it would produce big returns, be it in today’s corporations or in “communities” in all sorts, hence incredible waste of time and efforts given - and literally an “internal brain drain” - to mean tasks.
Posted by Fredy
Sep 5, 2012 at 01:33 PM
Double Edit:
Last Edit here-above: Of course, I wanted to say, it’s wrong to say, we can’t AFFORD (to pay for) these efforts”, since the resources are spent anyway, they are just very badly attributed today.
“Inline outlining”: I just had a look into my 15years-old source code, and indeed, I had such (very basic) “switching” routines there already, even for just one indentation level only, both-ways: “Make the headings plus following paragraphs a sibling of the current item” (= the heading becoming the new item’s title; for this I “understood” that single-line paragraph were “headings”), and “Make the selected items (= all siblings) as body text, with headings”.
So it seems that I afterwards got too far away from this need, i.e. negated it, from lack of any “outliner” doing this switching for me (and not considering doing the necessary switching by hand, one paragraph / item a time, except when really necessary). Today, I see that with just a little bit of scripting, the same (= this very basic way, with just one indentation level and considering ALL content of a given item as such a body to be transposed into several sibling items) could be done within any outliner(2/3) of your choice - but here again, an array would be extremely helpful in order to do so, at least for the “paragraphs into different items” direction (= differentiating the paragraphs from the headings within a text body within memory, within the scripting language, not having the scripting language switch forth and multiple times between tree and content field, doing multiple cuttings and pastings - this is what differentiates a script from dumb macro execution), and again, even in AHK_L, even two-dimensional arrays are an awful and totally way-off any standardization thing to do - and of course, this “amateurish” character of AHK does bother me, again and again, so I’m not really happy with this “easy-access” scripting language.
But then, again: Why professional developers, in 2012, unable to integrate at least some basic, one-level switching between content and tree, when I was able to do it 15 years ago (and it wasn’t complicated for me): again, this “good enough quality” stance of theirs (even when what we’re asking wouldn’t be really an effort for them) is revolting imho.
Posted by Fredy
Sep 5, 2012 at 02:06 PM
And you need a command “make this paragraph / the selection a new sibling/child” (making the first line, if there is any independant first line above, the item’s name) - very easy indeed.
And the aforementioned group switching in both directions, most of the time, the (easy-to-script/program) just ONE indentation level is perfectly sufficient, since we’re speaking of the outliner(2/3) variety here where most of the time, you wouldn’t go for several indentation levels within the content - using an outliner(1) then instead -, but you would do - as in programming within an outliner - just the deepest level of your outline indentation within your text body, processing higher levels within the tree, and hence the necessity of shuffling your current deepest level (only) into the tree whenever you recognize the the need of further deepening your indentation within a given sub-tree, and, respectively, the necessity of combining several, originally separate items into just one item when you realize that here, there will not bee the need of further indentation you had initially foreseen. Thus, what at first sight doesn’t appear but as a pis-aller (since it’s basic but easy to implement), is in fact, even long-range, a viable, sufficient solution. But of course, a developer must first SEE that such a very basic solution, not asking much of his programming efforts, would indeed be perceived as perfectly satisfying by most possible users of his program, in order to not be ashamed of presenting it as a new feature. Hence the interest of for them to have some glance into this forum, here and then. ;-)
Posted by Slartibartfarst
Sep 6, 2012 at 03:30 AM
In your Opening Post you made a start in trying to gather an objective comparison - AHK vs. AutoIT.
You seemed to want to avoid repeating history, when you wrote:
“There are many “AHK vs. AI” posts in the web, but most of them are simply too much biased in order to be worthwile”.
I pointed to the issue possibly being lack of a handy comparison tool for carrying out a rapid objective comparison between 1 or more scripting languages - rather than making an(other) AHK vs. AutoIT comparison, and suggested a generic sort of “requirements-criteria checklist” approach for scripting languages.
That doesn’t seem to have appealed to you.
So we are presumably left with making the comparison - AHK vs. AutoIT - in this thread.
Though AHK-L seems to be a perfectly good scripting tool for my purposes - having used it for a while - I am ignorant of AutoIT.
Since engaging in this discussion, I have had a look over the AutoIT website, and I think it looks very interesting. I also noticed this:
“Also supplied is a combined COM and DLL version of AutoIt called AutoItX that allows you to add the unique features of AutoIt to your own favourite scripting or programming languages!”
Presumably, that might indicate that AutoX calls could be made from within AHK-L(?). So you could maybe try for the best of both worlds. I am not sure about doing it the other way - i.e., from AutoIt—>AHK.
Anyway, the idea seemed interesting, but I have not tried it.
Posted by Fredy
Sep 9, 2012 at 11:22 AM
Slatibartfast, for strict “ahk VERSUS ai” subject here, don’t count on me, but I’m certainly willing to share valuable hints for both script languages here, and I absolutely try to not becoming biased without further notice (which would perhaps be possible after better knowledge of text expansion within / by AI).
As for your triggering AI scripts by AHK, I didn’t try yet but it should be VERY easy, please let me explain (but perhaps I’m mistaken in part, corrections are always welcome).
Basics:
a ) Every (?) macro tool works in a similar / identical way: It’s running continuously even if you ain’t aware of this. So it causes a certain load on your computer resources, which may be more or less heavy perhaps, depending on the expertise it is programmed. The same goes for scripts that run continuously; here you also have YOUR say in determining the load since you can assign functionality (= by scope and context) by different ways (cf. the above link to the AHK forum I gave as an example - and a rudimentary example, without global variables to be constantly checked, let alone multiple ones).
Normal macro tools do NOT allow for you deciding upon the frequency the underlying script running again and again, neither does AHK for such continuously running scripts, but AI allows for your deciding upon it, so possibly such AI scripts can run in a more smooth way - this would have to be checked with very big scripts.
The continuous run - if you see it in AI or don’t in AHK or commercial macro tools - is, of course, because the tool / script has to intercept any possible key pressing and then to check if there is any special subscript to be executed, or if it is expected to let pass the key pressing, in order for your pressing “h”, e.g., in your text program, to become a simple “h” on your screen and within the text you’re producing.
In theory, a tool that doesn’t allow for simple keys, as the “h” in our example, could exert less such system load, since normal key pressings would simply bypass the running script, whilst it would intervene only in key combinations and “F” key pressings and such, but then, it’s only when you start to use even normal key pressings, like pressing of the “h” key, as special commands depending on scope and context that things become really interesting, so it would be dumb to confine your possibilities to “special key combinations only”.
Also, any key expansion would need “total interception” and not only the interception of special combinations, so you see that for any such tool, even a commercial one, it’s a good things to “intercept anthing”, hence a certain system load - if you had a 8088 processor, you’d certainly run into trouble then…
I do NOT think that running TWO such ever-running scripts simultaneously, would be a good idea, except for scripts with rather confined scope, e.g. I use an additional Cherry 4700 keypad, besides my normal keypad, and the 4700 script only works on the 21 keys of that additional keypad, without causing trouble (but on the other hand, AHK and AI are NOT able to intercept the commands sent from that script): if you want better functionality, you must buy an additional keyboard from Preh or X-Keys which have both inbuilt Eproms, which means there is NO running script there but you intercept the sent scan codes there by AHK or AI without any problem, in the form “key a1 on your Preh / X-Keys keyboard sends “shift-control-alt-a”, and AHK/AI does this command xzy whenever “shift-control-alt-a” is triggered”.
b) From these ever-running scripts, you must distinguish once-running scripts which can be done in any language, and which do NOT intercept key pressings, but just do what they are meant to do whenever they are triggered, and then close (or run forever by mistake if you made a programming error - I don’t say “scripting error” since I think that the activity might be called “to program a script” and not “to script a script” - there are distinctions to be avoided in order to avoid ridicule imo). For such “self-contained scripts” as you might call them, I think there is no problem whatsoever to trigger them from within everything, even from within any cheap macro tool that is able “to run a program”, and remember, the “ever-running” script (AHK, AI, or a macro tool) does NOT interfere here since it intercepts any (physical only? physical or “virtually physical”, cf. above, both script languages do NOT intercept other programs’ “key pressings” but scan codes only, even sent by virtual key combinations - Preh, X-Keys), hence it will “let run” your external script, just like it would “let run” any external program that it triggered. Hence I don’t see any special problems here, nor do I see special technical means needed in order to run such scripts, hence my thinking that there is total availability of such AI scripts from within AHK and vice versa.
Scope AND context
As I said earlier, some macro tools allow for “macro scope” = application scope, but very few allow for “micro scope” = scope within a given application, i.e. doing different things depending on which “control” of a given application has focus. But then, e.g., it’s evident you can almost double your normal key assignments if you have control over them depending on the alternative “focus within tree vs. focus within text field” of your outliner, let alone focus on the various panes within such outliners like MI or UR; the same goes for CT, of course.
All this is about using your NORMAL keyboard for most of your things, with “mnemonically decent” keys / key combinations, instead of having to multiply your additional keyboards (or to refrain from further scripting).
Btw, I own a Preh 128 keys keyboard, and I don’t use it anymore, since most of the keys there are WAY to far away from my main keyboard, and so, even complicated key combinations on my main keyboard are easier to trigger than many of my additional “simple” key commands on that expensive additional keyboard. On the other hand, Preh’s 30-keys keyboard is ideal for putting to the left of your normal keyboard (on which, of course, you’ll assign many additional commands on your numeric keypad (to the right; vice versa for lefthanders, of course) in most applications).
But I quickly have realized that “micro scope” just by “controls” is rather poor again: What about having a context: “Within your text pane, have the same keys trigger different commands, depending on the alternative, “is there something selected there currently, or is there not?”” - it’s evident you’ll have many new possibilities here, as soon as you are able to program (or for Slatibartfast: “to script”) this alternative; cf. here:
And so on, and so on, once you begin with all these, you quickly realize that most developers ain’t interested but in the money, and certainly not in the sheer excellence of their products, since everything we do here, with big pains, from the outside, they could implement INTO their programs, from the inside, making them sheer pieces of art.
But no. Which leaves room for us to do a little programming of our own, called scripting. ;-)