AutoHotkey Community

I would usually call them taskbar buttons. I will have to think about how to tell what window it is.

_________________

(Common Answers) - New Tutorials Forum - Humongous FAQ

also hotkeys dont work accurately

isnt there a solution to make what ahk does but in an OS-level?

If you are able to do better than Chris in low level Windows programming, we would love that you share your knowledge, Chris would surely integrate any improvement you could suggest! (if effective)

the problem is "low level windows programming" isnt sufficient, "OS-level" would be robust and stable and fully-featured

but since windowsXP isnt open source, I doubt it can happen

Uh?
Explain me the difference between Windows-level and OS-level when the OS is made by Microsoft...

If you mean the features must be integrated to Windows, they are already (or else, it wouldn't be possible), but they can be incomplete or buggy...

Which hotkeys, and inaccurately how?

If you mean keyboard simulation, I imagine any limitations (such as DirectX support/support for games) could be overcome by implementing a virtual keyboard driver. However, that would most likely require someone with sufficient C/C++ (and driver development) knowledge and access to the Windows DDK (Driver Development Kit).

Some (few) aspects of hotkey detection might be more reliable if implemented at the driver-level, but I think that would require replacing your current keyboard driver (which would not be an option for some keyboards.)

All in all, I rarely encounter limitations of AutoHotkeys ability to intercept hotkeys/simulate keypresses. Even then, workarounds are usually available.

I didnt say Windows-level, I said low-level-programming (for Windows)

the difference is that to do something in an OS-level, you dont script, you change the OS from inside to make it perform the way you want, you dont just trick it

ahk is tricks

it tricks the winxp to do what you want, it doesnt change it

thats why it is not robust, solid, accurate and fast enough

one among numerous examples is when you want to hide a popup window: with ahk you monitor for it (this consumes your pc resources), then when it detects it, it kills it

this approach, when your pc is heavy loaded, it will make the popup flash, which is annoying

in an OS-level programming, you would alter the OS from inside and make it just not to display that popup and there will be no flashing and no system resources cunsumption

The problem is that to do it the way you describe it, you must modify the sources of the OS and recompile it.
But Windows isn't open source yet...
Now, it offers some openings, like device drivers, hooks, code injection, DLL substitutions, etc. But these solutions are high level, needing advanced Windows programming knowledge, and some of them can be seen as intrusive or highly suspect by the users (methods used by rootkits, keyloggers, spies...).

anyone made a comparison of ahk with:

Windows PowerShell
Windows Script Host
KiXtart

??

What about DIY? Why?? Because in 99,99% of all cases it's finaly a matter of taste.
And you might know already: 'degustibus non est disputandum'

Would you really expect an usefull answer if the question would be: "anyone made a comparison of women?"

And because you didn't gave any criteria to check for, I wouldn't start such a comparison anyway.

Well, you obviously ask on wrong place, as ppl here are AHK lovers (obviously) and are not very objective.

Power Shell is state of the art thing IMO, but its a shell, not automatition tool. As you can use entire dotNet from it, I imagine you can automate Windows using Ranorex library.

Windows Script Host runs JS and VB scripts which are not made for automation in mind - you can make automation scripts but then, you have 0 benefits in that topic - you will have to use low level API or COM. The same goes for KiXtart, which I never used, but one look at it reference manual proves me that it tries to be general scripting language.

AHK, AU3, Phanotm, WinRunner, Ranorex etc... are made with automatition in mind, so they are better in that domain.

Anyway, all the things you complained can be done in AHK today. Its hard, but doable, and AHK is very reriable IMO.

_________________

AHK is got cool functionality, and has pretty way for some little actions. But it is a torture to write and support something longer than 100 lines. Language itself of AHK 1.0 is ugly and inflexible. AHK 2.0, as i see it - little far from it. No notmal debugger, no normal ide.
Best and only solution now is remade it like library with bindings for any modern platform with big comunity, tons of own sourcecode and normal production enviroment, something like .NET or CPython.

And yes, almost all of ahk script archive is a useless toys written for fun. No need for trying tow that ballast.

imhoho

@garkin_
Everyone have other needs. Every language and environment have its own strength and week points. In example with AutoHotkey it is very easy to work with hotkeys and things like activating specific windows than in .NET and Python and much more. Also, AutoHotkey is very small single executable and the compiled version of your script is very small and portable too. If you are happy with anything other, than use it.

Lies.

And please don`t start any war. Good luck with your decision.

_________________
{1:"ahkstdlib", 2:"my libs", 3:"my apps", 4:"my license"}
--> Don't feed the troll! <--

@Tuncay: Don't feed the Trol

I am care only about AHK weak sides: bad source library, another ugly custom language and lack of normal ide.
And i am, but available solutions laks AHK functional realization comfort (nor portability, lightweight (on windows PC, lol) or some other rainbow unicorns). Currently i am trying to utilize and honeycomb ironAHK libraryes in c#.
Ok, as you say.