AutoHotkey Community

[AHKnow]

AutoHotKey.NET? Yeah, maybe this should be done. Now before people start jumping on the anti-Microsoft wagon, read some more first.

1. Microsoft has standardized C# and their Common Language Infrastructure (CIL) with the EMCA. This means that this aspect of .NET is an international standard, just like C or C++. Even Java, despite its popularity, is not accepted as widely as an international standard (this is also partially due to Sun's insanity, which has really hurt Java). Also, I think Microsoft is really going to "stick it to Sun and Java", by bashing it over the head with .NET.

The future of .NET languages is mostly assured. As a result many companies and organizations are going to create programs and products that adhere to this standard.

2. Projects like Mono ( http://www.mono-project.com/Screenshots ) and DotGNU ( http://www.dotgnu.org/ ) have created freeware alternatives to Microsoft's .NET framework (based on the EMCA/ISO standards) and allow .NET programs to run on LINUX and MACs.

This would also mean that AutoHotKey.NET could run on Linux and Macs too.

3. AutoHotKey as a .NET would increase developers and tools for the language. A person that knows VB.NET, Lisp.NET ( http://www.lsharp.org/ ), Forth.NET ( http://www.dataman.ro/dforth/ ), Perl.NET, Jscript.NET ( http://www.gotdotnet.com/team/jscript/ ), etc.. can all be potential developers for AutoHotKey.

For those that are not familiar with .NET... In a nutshell all .NET languages get "broken down" to MSIL/CIL (Intermediate Language). C#/VB.NET/AutoHotKey.NET > MSIL/CIL > .exe Therefore all .NET languages have a common language among them. With .NET what language you choose is more about your personal preference, than it is about power or performance.

More on MSIL/CIL:

http://www.codeguru.com/Csharp/.NET/net_general/il/article.php/c4635/

http://weblogs.asp.net/kennykerr/category/7140.aspx


4. AutoHotKey.NET would have advantages as a way easier to understand programming language that could possibly make programs faster, in addition to its automation/macro-recording functionality.

P.S. links to free C# tools for those that are interested...:

SharpDevelp IDE for .NET (C#, VB.NET... free and with source...), an alternative to Visual Studio.
http://www.icsharpcode.net/OpenSource/SD/

CS-Script ( C#... free and with source... )
http://www.members.optusnet.com.au/~olegshilo/index.html

CSI ( C# interpreter... free and with source... )
http://www.codeproject.com/csharp/csi.asp

EDIT:

C# Tutorials (from many different sources)

http://www.programmingtutorials.com/csharp.aspx


What do you guys think about this?

[Guest]

And for all those that do not want to install the .Net Framework? Not to mention the need for keeping up to date with new releases.

[Chris]

Thanks for the very informative post. It's an introduction at the highest possible level. This is something often hard to find when you search the web, though it's usually easy to find something obviously biased, such as from Microsoft itself. But now that Wikipedia has emerged, maybe we'll be able to spend less time searching and more time learning. Incidentally, here is Wikipedia's entry for Dot Net.

I'll have more of an open mind toward Dot Net in the future. However, creating a .Net version of AutoHotkey would likely be hindered if .Net lacks support for the low-level OS features used to support hotstrings and custom hotkeys, among other things.

[Nemroth]

[AHKnow]

There is no stopping .NET We can't turn back the clock.

The next version of Windows will be making greater use of it and the Mono and DotGNU clones for the .NET framework are well on there way for Linux and MACs. You also have a modified .NET framework for Pocket PCs too.

Microsoft has also been pushing their Visual Studio product to adapt to .NET as well via C++.NET in addition to C# and VB.NET. Also, numerous other program languages are modifiying themselves to work with .NET

AutoHotkey can get ahead of the coming "wave".

I think CS-Script (C# script) might be a way for AutoHotkey to get the best of "both worlds", short of a conversion to an AutoHotkey.NET. A "add-on" language of AutoHotkey might be created and/or an alternate AutoHotKey compiler. This opens the door for AutoHotKey to do things like:

. Make DLLs

. COM/ACTIVEX

. OO ( object oriented programming )

AutoHotkey can be viewed as an automation and simplified programming language built over C++. You are taking things that are really hard or what people don't usually do in C++ and making them possible with AutoHotkey.

Why not do the same thing with .NET? CS-Script is basically C#, but with a more "pro script" slant. Thus making it great to be used by AutoHotkey in the same way C++ is used now.

Making a move for AutoHotkey source code all the way to .NET may not be bad either. We are now talking about having AutoHotkey run on LINUX and MACs and perhaps Pocket PCs, in addition to all the other things you can do with a .NET language.

[Nemroth]

Of course AHKnow, I know what you said. I know the basics of C and C++ and I don't know (for the moment) C#, nor CS-Script of course. But I think that C#-Script must be a script language simpler than C# but more complex for non programmers than AHK (witch of course is more specialised too).
.Net is an upper level above API, so probably that what can be done in C# and it derivatives can be done in C++, probably with more difficulty but also with more speed.
The philosophy of .Net seems to be the same as the one of VB : you can't make stand alone EXEs, as they need the .Net framework to be present to be able to run, as in VB you need the runtimes to be presents. In each case, the code of the exe is "semi-compiled".
Not all the AHK users are programmers, able to programm in C# or in C#-Script. I think it is the opposite. Probably more of them like AHK as it is easy to learn and with a basic knowledge, you can do interesting things.
I don't say it's a bad thing to be able to interface (if possible) AHK with C#-Script. I think it is probably more usefull to interface it (in a first time) with a more well known script lagnuage like WSH (in witch there is also COM/ActiveX capabilities) or VBscript.
One is not exclusive of the other.
And I maintain that if there are people who don't whant to install the .Net framework, even if it will become an important piece of software in the Windows environnement, they must be able to do so without other penalty than the one to not be able to run the .Net dependant progs.
For my point of vue, .Net is (as "semi-compiled") slowler than a stand alone exe and I don't think there is anything (or at least that there are only few things) new with .Net.
That's only my opinion.

[Guest]

I think that .Net works well in a corporate environment where there is control over deployment. In the "public arena", not so well.

[corrupt]

[savage]

[AHKnow]

I have nothing against the idea of a AutoHotkey .DLL version that can be uses in mutiple program languages. I'm all for a AutoHotkey DLL.

Some counter points:

1. There is also SWIG to consider when making the argument about P/invoke.

http://www.swig.org/ Ok, I admit swig is a bit funky, but maybe there is something there...


2. There are some macro recorder utilities for .NET out there. The below shows it can be done...

http://www.codeproject.com/csharp/GlobalSystemHook.asp

http://www.codeproject.com/csharp/globalhook.asp

note- you may have to join to download source code.


3. This speed thing can be very relative. C# is not going blow away C++ in a speed contest, but there has been a lot of comparisons that show C# is not slow either. We also are talking about recording and playing back recorded macros in many cases, not about time critical applications where a few seconds makes all the difference in 95% of the cases.

4. What about bringing AutoHotkey to the LINUX and MAC world? Oddly enough, .NET seems to be the best way to try to do it.

[Nemroth]

I will not come back on what I already said about Net
I don't see why to adopt .Net, C# and C#-script as a priority.
I think they are other things more important.
OK (not immediatelly of course) to have AHK in a DLL usable by other programming and languages, OK to be able to manage ActiveX, DOM/COM, etc..., but why with the intercept of .Net ?
Hooking ? This technique exists since windows 95 (I'm not sure it was avaible in Windows 3.11, but it isn't impossible...), so it isn't a discovery !!! It is avaible in C# ? Good thing, but as it can be done with C++ since a long time (I speak of course about hooking inside a DLL, not about the form of hooking used by AHK), I don't see any advantage to do that with C# and .Net, as it is only a translate of things witch already exists.
And it is a translation witch is less powerfull than the C++ solution.
Bringing AHK in Linux and MAC ? I'm not certain that .Net is the best solution for that...

[daonlyfreez]

I'm already doubting the direct and full support of ActiveX/DOM/COM/OLE/MCI etcet., and certainly of .Net.

AutoHotkey does work on the Windows platforms, but full support (and undoubtingly more implementations that use it) would make it far to dependant on it, I fully agree with Nemroth. Some functionalities might need a 'form of'/calls/hooks, but that should be basic only.

E.g.: I installed Limnor to give it a try, which has almost full 'Microsoft' objects control support, and it errored out on the install, complaining about my MDAC (database drivers) not being up to date, which isn't true. I don't want to have to have all and latest drivers/updates/fixes installed to make something work, I think nobody does.

We can do without using Access as a database, Excel as a spreadsheet, and Word as a wordprocessor. If data is in there and you want to/have to use it, it would ofcourse be convenient to have an easy way to pull it out/put it back in, maybe even thru basic AHK support, but advanced use please as an add-on, a dll or whatever...

I feel since AutoHotkey is free, simple and open source, the functionalities/support added should be so too. DLLCall is complicated enough already

There is more need for support/libraries like CMDRet/StinStout (CMDRet, but with full 'tailing'), Serial (serial port support), IR (infrared support), mySQL (database support), HTML/BrowserControl (an addition to the GUI controls, but DISABLE ActiveX please, for support for it would really leave the door open for abuse) and RichEdit (advanced editing as a new GUI control), cURL (advanced net) etcet. etcet.., as a dll, an include, functions or direct support in AHK.

What do you want to achieve with full support for ActiveX/DOM/COM/OLE/MCI etcet. exactly?

And what can .Net/C# do that is so special (apart from downloading a huge install in the case of .Net)?

If need be, you can still use a temp-file, the environment, the command line or whatever to launch someother 'language', like VBScript
_________________
(sorry, homesite offline atm)

[specialGuest]

[Nemroth]

[daonlyfreez]

I'm not saying basic support for getting data in and out the MS Office applications (Access, Excel, Word, Outlook, or even the satan itself: PowerPoint) wouldn't be a good thing! If some access to ActiveX/COM etcet would be necessary to achieve that, so be it.

But...

If you allow full access to those, soon scripts would arise and soon the standard for using databases would be Access, we'd have an Access Control, since, well, the code is there anyway, why not use it..., for spreadsheets one would use an Excel Control, we'd have a Word Control in our GUI etcet....

Sounds all good for those who have it, but makes it inwillingly or not the standard, thus incompatible for those who don't have Office...

I'm not against Office or Microsoft, and I'm not that dreamy that I don't realise that most work with it, I do myself, all day. Automating those in an easy way would be a very nice addition, but I think the core of AutoHotkey should depend on itself, and (not much more than) the standard OS install. Any nice add-ons, like a dll, no problem, I don't mind FileInstall, excellent... Isn't there an open source OLE library out there? That would cover most, right?
_________________
(sorry, homesite offline atm)