AutoHotkey Community

From this post about a DLL version of AutoHotKey http://www.autohotkey.com/forum/viewtop ... sual+basic I gather you might not be too enthusiastic about just copying AutoIt. I suggest that some commands for greater support of VBScript be added. Other macro recorders like Macro Scheduler or Aldo's Macro Recorder have high levels of VBScript support. A program called macroangel 2 / macro angel 2 also has support for Visual Basic for Applications. There is also a freeware program, which in various ways is less advanced but in others more, called MediaBasic ( http://www.uolang.org/mediabasic/ ) that can directly compile .vbs files into .exe.

VBScript support would allow AutoHotKey executables to do more with less need for supporting files or other external scripts and give them greater functionality.

I just put down a little visual of what I mean, but of course however it would be done, it would be very useful.

VBS_START ("Inputbox", add whatever)
dim response
response = inputbox("Type anything in the box and click OK.", "Input box demo")
if response <> "" then
msgbox "You typed " & response & ".", 64, "Your Input"
end if
VBS_END

VBS_RUN ("Inputbox", "cscript")

VBS_START and VBS_END could kind of be like #include, but are inside of the script as oppose to calling another script externally.

VBS_RUN could be a modified version of a command like RunWait('cscript.exe "c:\long file\name\script.vbs"') But where RunWait was was getting the VBS script externally, VBS_RUN would use what is between VBS_START and VBS_END and could send that to cscript.exe or wscript.

Of course if some other way was found for AutoHotKey to compile VBS than that would be even better.

EDIT- installs VBScript help doc in .CHM format (might be useful at some future point)
http://simplythebest.net/software/dll/vbscriptdoc.exe

Visual Basic for Applications free tutor
http://www.users.bigpond.net.au/gradley ... .htm#Part1

That's good. I'll see if this can be done for a future release, perhaps by learning from the source of MediaBasic or finding some info on MSDN about how to integrate VBS.

As always, development help is welcome from anyone, whether it be in the form of finding source code (as you did), contributing code, or finding technical articles that explain how to program specific things such as integrated VBS support.

I think that, rather than just vbs, if you used activescript instead, thus enabling the use of vbs, jscript, perlscript, rubyscript, or whatever. Unfortunately, my knowledge of how to set this up is limited to VB .

As I know Macro Scheduler for a long time, the need to add additional commands was less important from that moment, as it was possible to use VBS with it. Here's a sample command how it uses VBS: VBStart

Related to that... I found these interesting...

http://msdn.microsoft.com/library/defau ... d=28001169 (Microsoft Active scripting info.)

http://activescript.port5.com/index.html ( ActiveScript for Delphi )

http://www.geocities.co.jp/SiliconValle ... /main.html (ActiveScriptRuby)


Also... for MediaBasic ( http://www.uolang.org/mediabasic/ ) you have to copy the contents of a/your VBScript into their IDE and then compile it. MediaBasic understands the VBScript language syntax.

Hmmm.... I was doing some studying on one of the ancestors of AutoHotkey and AutoIt.... Her name is Scriptit and it was a command line automation/install program made by Micro$oft and may have been "copied"/based on an early version of WinBatch. Well, it seems that it was Micro$oft's intention to have Scriptit able to "call" VBScript, JScript, etc...

info from http://www.microsoft.com/technet/prodte ... iptit.mspx

MkFile

ScriptIt does not have many of the sophisticated features of traditional scripting languages such as Microsoft Visual Basic, Scripting Edition, Microsoft Jscript™ development software, or Perl. However, the mkfile line allows you to enhance and extend ScriptIt's capabilities with the features of these other scripting languages. The mkfile line capability allows ScriptIt to write a Visual Basic, Scripting Edition, Jscript, Perl script, and so forth, at run time. The external script can then be executed using a ScriptIt run or runwait line, or it can be executed from a title line using the left quotation mark (`) directive as described earlier. This will result in the standard output of the external script being redirected to the designated window title. Note that when you use any of the supported Windows Script Host languages from within the context of a title line, you should use CScript.exe, not WScript.exe, to launch them. ScriptIt expects that any command launched from a title line will send its output to standard output. WScript.exe does not use standard output.

Syntax

mkfile filename.ext=fileline

The parameters are as follows.

filename.ext

This parameter specifies the file name that is to be created or appended. Environment variables such as %Temp% can appear in the filename string.

fileline

This parameter specifies the line that is to be written or appended to filename. This line could be Visual Basic, Scripting Edition code, Jscript code, Perl code, and so forth. Or it could just be normal text that you want to save in a file.

If you want to create a multiple-line file, you need to include multiple mkfile lines in your script, each with the same filename.ext. The first instance of a given filename.ext opens a new file. All subsequent mkfile lines with the same filename.ext append lines to that file. Once you have finished building your new external script file, a ScriptIt run or runwait line can execute it. As indicated earlier, you can also redirect your external script's output to a specific window by using a ScriptIt title line with a keystroke segment that begins with the left quotation mark (`) followed by the command-line necessary to run the external script. For example, the following uses a run line to launch an instance of Notepad:

run=notepad.exe
mkfile %tmp%\t.vbs=set wshshell=wscript.createobject("wscript.shell")
mkfile %tmp%\t.vbs=set wshnetwork=wscript.createobject("wscript.network")
mkfile %tmp%\t.vbs=wscript.echo wshnetwork.username
Untitled - Notepad=`cscript //nologo %tmp%\t.vbs
run=`if exist %tmp%\t.vbs del %tmp%\t.vbs

It then uses mkfile lines to build a three-line Visual Basic, Scripting Edition file named %tmp%\t.vbs, and then uses a title line and a command line preceded by a left quotation mark (') to run t.vbs, redirecting the output to the Notepad window. Finally, the ScriptIt script cleans up after itself by using a run line with a left quotation mark to delete %tmp%\t.vbs.

You can download this old grandfather of AutoHotkey and Autoit at - http://www.csst-technologies.com/Automa ... 20Utility/

I really hope a way can be found to include this type of functionality.

Great links, thanks!

Also, I did know about ScriptIt, but not about it's extensions described above. Thanks also for that info.

I use WinBatch a lot and recently started using AHK because it works better for capturing hotkeys. One thing they recently added that solves a lot of problems in one shot is the addition of basic Active-X support. You can use syntax similar to Visual Basic's CreateObject to open any active-x control. This very nicely solves a lot of problems.

For example, my most frequent use of this is to get Regular Expressions (something else on your wishlist). I just use VBScript's regular expressions and life is good. You can also use Active Scripting to fire up VBScript or JScript itself, although I very rarely do this.

If you could do something like they did with Active-X support, a lot or your wish-list items would go away immediately.

Confirmed
If you look at Macro Scheduler (Shareware) it follows the same route (as it allows to include/implement VBS within its native code) That would be of help for all of those who are familiar with such a "second" language.

On the other hand, AHK's benefit (like it was with AutoIt2) is its simplicity.

If it comes to complex tasks it's worth to think about to find the right hammer/tool for a specific nail/issue, as IMHO its legitimate to use an ATV instead of a Ferarri if you've to cross a muddy acre (if available ).


Man, you should definitely have a look at Perl(/Tk) or Tcl/Tc or ...

Last but not least (I guess Chris would recommand this too: AutoIt2/3 offers an Active X module (?), maybe it could be used with AHK as well (???))

Thanks for mentioning it and describing it so nicely. I'm definitely going to research this to find out how difficult it is to include.

FileAppend is pretty close to the orginal wish for this feature, though its not so clear by name or example that it could be used for the purpose of executing other scripting languages in AutoHotkey.

AutoHotkey, by virtue of FileAppend has activex/com/ole (in a way) because it can simply FileAppend VBScript code to a text file and execute it.

You can even use this for .NET languages like cscript (C# script) and various .NET scripting programs.

Example using VBScript, fso, CreateObject, etc....



I think this aspect of AutoHotkey should be emphasized. Why?

1. In many situations, this type of ability is the equal of AutoitX.dll or its built-in Activex/OLE/COM.

Programmers from other other languages can use their favorite code inside of AutoHotkey for various problems that they encounter.

2. AutoIt's AcitveX is a copy of VBScript. So why not use the real thing?

Even better, you can use more than just VBScript or Jscript.

3. Many AutoHotkey programmers don't have to wait for certain type of increased functionality in AutoHotkey, because while waiting they can use any scripting language that can use wscript or cscript, like Jscript , VBscript, or Perl. They can also use various .NET scripting languages that use VB.NET or C# script ( http://www.codeproject.com/csharp/cs-script_for_CP.asp ).

I was wondering if "FileAppend", "Run", and/or "RunWait" could be enhanced a bit more or a similar command created that specifically deals with handling other scripting languages and .NET??

A big enhancement would be to see if you could pass the commands to wscript or cscript without a temp file or .dll (like cmdret (great program)). I know its been talked about, but that would make this kind of feature even better.

I think the target language's interpreter would have to have built-in support for reading the commands from stdin. Does anyone know if VBScript or the others support this?

One problem with using FileAppend is that the script to be executed won't have access to any AutoHotkey variables, though I imagine you could pass parameters in via the command line. Another question is how to get data back out, which could be done via the exit code (for a single integer) or by having the external script write to stdout or a file.

I seem to remember that some macro languages allow seamless integration of VBScript so that both languages can see each other's data.

Thanks for the ideas.

If this command was tweaked perhabs it could be like...

OtherScript, , (maybe some other commands),

(

Whatever the scripting language

), (maybe send to "Clipboard" and/or "tmp" file), cscript.exe (whatever .exe used to run other script).



Note: Perhaps you could have the contents of the clipboard piped to cscript, wscript, etc...



That works, so why not from the clipboard?


Anyway, these type of commands allow Autohotkey to do whatever else you need to do too. Even if that was ActiveX/COM/OLE, .NET, something in Perl, compiling a .NET DLL, etc.. it would not matter.

AutoHotkey advantage over the others will be its simplicity and/or automation abilities. Nevertheless, as AutoHotkey develops, there may be something people want from another scripting language. AutoHotkey could provide the "best of BOTH worlds", so that people can do whatever they need to

Perfectly agree with the integration of VB Script in AHK.
May be this link about the "implementation of Active Script Site with ATL" may be of help ?
And may be this one too ?

Thanks for the links and ideas. This will make my research easier when I start looking into COM, OLE, VBScript, and Active Scripting.