Jump to content

Sky Slate Blueberry Blackcurrant Watermelon Strawberry Orange Banana Apple Emerald Chocolate
Photo

Visual Basic Script support in AutoHotKey


  • Please log in to reply
54 replies to this topic
not-logged-in-daonlyfreez
  • Guests
  • Last active:
  • Joined: --
is there anything wrong with this?

TempFile = %temp%\aVBScriptInAHKTest.vbs
VBScript = 
(
r = MsgBox("This message box is a VBScript that was incorporated in AHK and launched thru a temporary file", 65, "MsgBox")
)
FileDelete, %TempFile%
FileAppend, %VBScript%, %TempFile%
RunWait, %a_windir%\system32\cscript.exe "%TempFile%", "%temp%", hide
FileDelete, %TempFile%


Nemroth
  • Members
  • 278 posts
  • Last active: Dec 31 2011 10:53 PM
  • Joined: 07 Sep 2004
There isn't anything wrong with your example, except I'd like to avoid using external file (even temporary). But it seems (at this step of my search) that you must provide a file name to cscript.exe in order to make it work proprely. A variable's content seems to not be OK.

I'm trying to see if it's possible to send to the executable, in place of the file, the clipbaord content (for example).

If it is, it can be a way to solve (my) interrogation.

Thanks for your solution, daonlyfreez.

corrupt
  • Members
  • 2558 posts
  • Last active: Nov 01 2014 03:23 PM
  • Joined: 29 Dec 2004
While I can see certain advantages to being able to in-line code from other languages, I'm not convinced that it is worth the effort or additional code that would likely need to be added to AHK.

Creating a temporary file then executing it is probably the easiest method and wouldn't require adding additional code to AHK. CMDret could be used to run the external script and return the output (depending on what the external script does of course - if returning output is desired). Chris will likely add CMDret functionality (in some form) to AHK if you are trying to avoid adding an additional file to a project.

Although I realize that it is only a suggestion, I would like to see this type of functionality stay far away from the clipboard if it gets implemented. The clipboard was/is typically designed for the user and will likely contain data that a user wants to transfer to another application from time to time. If applications start using the clipboard for transferring non-user data it increases the possibility that the user's data will get lost/corrupted. Even if the application saves a user's clipboard data first then attempts to restore it there is still the potential of data loss. The application may not be able to restore the data to the clipboard properly, or (very likely) the user may try and paste the data into another application while the script is running and end up with a pile of garbage that may end up crashing both applications. Of course there is always the possibility that a user might copy completely different data to the clipboard while the script is trying to read and write from it (again, possible data loss and more possible crashes), etc, etc...

There is another possibility for extending AHK's features. You could create a .Dll using a different language and then use DllCall to use the Dll's functionality in AHK...

Nemroth
  • Members
  • 278 posts
  • Last active: Dec 31 2011 10:53 PM
  • Joined: 07 Sep 2004

While I can see certain advantages to being able to in-line code from other languages, I'm not convinced that it is worth the effort or additional code that would likely need to be added to AHK.

May be the code to be added would be reasonably short, and consist in the ability to send (following the subject of this topic) a variable content to the command line of cscript.exe rather than a file, even temporary (why not by the mean of a pipe if it is possible...).

Creating a temporary file then executing it is probably the easiest method and wouldn't require adding additional code to AHK. CMDret could be used to run the external script and return the output (depending on what the external script does of course - if returning output is desired). Chris will likely add CMDret functionality (in some form) to AHK if you are trying to avoid adding an additional file to a project.

It can be a lot of write/del on the hard disk if there is an important usage of VBScript. I don't see any advantage of a temp file. If you want to execute code witch is in a file, why use a temporary one ? I want to avoid the possibility for the user to see and modify the source code (even by accident). If it is possible to use memory (clipboard, pipes, variable send to command line ... ???) to do that, it can be very interesting.
I know the quality of CMDret and I'm glad it will be integrated in AHK, and I will use it in it's DLL form of AHK-converted form to retreive results from command line apps, but here I don't want to retreive, but to send.

Although I realize that it is only a suggestion, I would like to see this type of functionality stay far away from the clipboard (...) Of course there is always the possibility that a user might copy completely different data to the clipboard while the script is trying to read and write from it (again, possible data loss and more possible crashes), etc, etc...

Absolutely, completely, definitively agree. You're right !!! That's true, I said "the clipboard content", but I added "(for example)". If it can be done by sending a variable content, by using pipes (nammeds or anonymus) or any other (safe) way, I am taking !!! In this case, may be it will be necessary to have an AHK command to do the trick.

There is another possibility for extending AHK's features. You could create a .Dll using a different language and then use DllCall to use the Dll's functionality in AHK...

"You" could create ? I am not corrupt, the CMDret's father. I don't know how to do such a miracle !!! I exaggerate a little for the miracle, but it's true : I can't imagine the first line of code to do that, and I think it must be hard to do (at least for me).

So, if it would be possible, I'd like to see in AHK the possibility to send a variable content (in witch the script in VBS, for instance, would be stored) in place of a command line parameter.
That would make it possible to carry out a great number of script languages, of which the exe await a file name to execute in argument on the command line.
The benefit ? To brings (for example with VBS) to AHK a quasi endless number of new capabilities, like ActiveX/COM/ADO support, etc... with only (at least I think so) some lines of code...

daonlyfreez
  • Members
  • 995 posts
  • Last active: Jan 23 2013 08:16 AM
  • Joined: 16 Mar 2005
I do see benefits in 'incorporating' the possibility to 'directly' call other languages (in general), and - more importantly I guess - to receive data back.

However, asking for incorporation into the distributable of AHK - I feel - is too much, for:

1. It would require constant updating of code for the different versions of the script interpreters used on different OSses, their paths, their methods, their expected variables, the errorlevels and data they return, etcet.

2. It would not only require 'standard' compatibility, but - to make it smooth - compatibility with 'all' different packages/builds of the script interpreters, which - in some cases - can be quite many.

3. It would distract the focus from AHK itself, ready-made other-language scripts would be incorporated eventually in the - to be - standard library, which would make it even more difficult to maintain.

4. Scripts would emerge that would require a mixture of different scripts and their interpreters, not only AHK, which - fortunately - can work almost independent. Again, soon one would have serious compatibility problems with different versions of interpreters used etcet. (see 1.). Users would no longer have the comfort of knowing it is AHK, so it runs :wink:

I would strongly suggest that those who want or have to use VBScript or JavaScript or any other language directly, or better, that have snippets that might be able to do things that AHK cannot do yet, make an effort, and convert it into an #includeable. Small useful snippets are probably speedy enough if launched thru temp-file. If speed becomes an issue, or if returning the data seems impossible, in the long run - maybe an other-language-plugin (dll/cmd) could be developed to get the data in and out of the other-script from AHK, with DLLCall/CMDRet...

VBScript (cscript.exe) apparently needs a file anyway..., ofcourse, if you find a better method, like piping (not the clipboard, it's NOT for data transfer - well, only if everything else fails), do let us know...

Launching JavaScript can be done thru direct loading from the addressbar, or thru launching a bookmarklet/bookmark/shortcut/url-file with the same content, or... other hacks are available too, if need be.

Launching a Perl script is also 'dropping a file on the interpreter', as it is with most I think...

I would definitely welcome AHKPlugIns that can easily control other languages, like a nice AHK savvy mySQL.dll, cURL.dll, (or VBScript.dll :p ) etcet. (or as an #includeable, or function), but I think supporting it directly in AHK really is too much...

Take the good things from those languages, the things AHK can't do yet, and create a library to use it... maybe one day it will be incorporated in the AHK standard library :wink:

I would much more welcome focussing on improving AHK directly, like that one could eventually do loop, parse on other datatypes, an access/excel/word/powerpoint for example, and (binary) filewrite support back in. This would need separate plugins (to keep AHK small), and should only be focussed on the direct functionality, like DLLCall... Hook into COM, use ActiveScript, whatever to make it work, but why support for the whole available underlying codebase? ONLY the nice-things-AHK-can't-do-(yet) please!

Creating small AHKPlugIns would be improving AHK itself, you'll do the parsing and coding in AHK, NOT in the other languages. Easily pull data out of, and put it back in as many as possible types of sources? Yes please, but I want to work with the simple AHK syntax, I want to do the manipulation in AHK! Not in other languages!

I think we really need 'certificated' #includeable libraries/AHKPlugIns (dlls, exes), with an easy to use set of functions/calls! A good example is the WinLIRC code, which is a clear candidate for the standard library. There are numerous interesting codes in the forum too...

In general, improving CMDRet with the option to monitor input continuously, and incorporating CMDRet directly in AHK would already solve these kind of control wishes, and extending the data-types AHK can handle too :wink: ...
Posted Image mirror 1mirror 2mirror 3ahk4.me • PM or Posted Image

Nemroth
  • Members
  • 278 posts
  • Last active: Dec 31 2011 10:53 PM
  • Joined: 07 Sep 2004
daonlyfreez, in place of doing that :

TempFile = %temp%\aVBScriptInAHKTest.vbs
VBScript = 
(
r = MsgBox("This message box is a VBScript that was incorporated in AHK and launched thru a temporary file", 65, "MsgBox")
)
FileDelete, %TempFile%
FileAppend, %VBScript%, %TempFile%
RunWait, %a_windir%\system32\cscript.exe "%TempFile%", "%temp%", hide
FileDelete, %TempFile%

I'd like to do something like that :
VBScript = 
(
r = MsgBox("This message box is a VBScript that was incorporated in AHK and launched thru a temporary file", 65, "MsgBox")
)
RunWait, %a_windir%\system32\cscript.exe "%VBScript%",, hide

I think that would be sufficent to run a VBScript, or many other scripts in script languages of witch the executable support command line call with a file name as one of the parameters.

May be that would a a little improvement of the AHK code, of witch the KB cost would be little.

asking for incorporation into the distributable of AHK is too much

I asked for that, it's true, but if the upper solution can work, it would be of course sufficent. The goal is to be able to increase the power of AHK by the possibility to use other script languages, witch have other forces, other advantages in others domains, like VBScript for its ActiveX/COM/ADO capabilities.

VBScript (cscript.exe) apparently needs a file anyway..., ofcourse, if you find a better method, like piping (not the clipboard, it's NOT for data transfer - well, only if everything else fails), do let us know...

I don't know how to do that (nor if it is possible), if it was the case I would have done it for a long time, and I would have shared my discoveries... I ask for it to those which are suceptibles to do it (if it is possible) !!!
With this way of doing things, the VBScript (or other script language) can be embedded in a compiled AHK script and executed. If you use a temp file, its content can be recovered. If you want to protect your source code, it isn't desirable. For the remainder, please read carrefully my precedent post :

That's true, I said "the clipboard content", but I added "(for example)". If it can be done by sending a variable content, by using pipes (nammeds or anonymus) or any other (safe) way, I am taking !!! In this case, may be it will be necessary to have an AHK command to do the trick.

And then :

Take the good things from those languages, the things AHK can't do yet (...)

So AHk can continue to focus itself on its characteristics We are perfectly agree on this point.

Chris
  • Administrators
  • 10727 posts
  • Last active:
  • Joined: 02 Mar 2004

...AHKPlugIns that can easily control other languages, like a nice AHK savvy mySQL.dll, cURL.dll, (or VBScript.dll :p ) etcet. (or as an #includeable, or function)

I think we really need 'certificated' #includeable libraries/AHKPlugIns (dlls, exes), with an easy to use set of functions/calls!

I've been procrastinating on publishing any sort of standard library. If someone has an interest in helping with it, I'd welcome it. The task entails a high level of quality assurance and documentation, both of which are time-consuming. Quality assurance is needed because standard library functions should rarely (if ever) be changed in a way that breaks existing scripts. Thus, the "API presented to the script should never change, which requires careful design.

Volunteers? :)

AHKnow
  • Members
  • 121 posts
  • Last active: May 17 2009 09:11 PM
  • Joined: 03 Jul 2004
Before I begin, please do not interpret this discussion in the wrong way, as I think it is wonderful that we consider and discuss this type of feature and how to get this to work with AutoHotkey.

I do see benefits in 'incorporating' the possibility to 'directly' call other languages (in general), and - more importantly I guess - to receive data back.
...


Yes, we agree, that there would be great benefit in providing syntax for the purpose of calling other languages.

Myself and others are mainly dealing with passing commands from a different scripting language to an .exe that understands that scripting language.

AutoHotkey itself, does not need to understand the syntax of the other scripting language. AutoHotkey is simply passing the syntax along to an .exe that does.


1. It would require constant updating of code for the different versions of the script interpreters used on different OSses, their paths, their methods, their expected variables, the errorlevels and data they return, etcet.


We disagree on that point. Nemroth and myself are talking about "Passing Scripting commands in another language, from inside an AutoHotkey script, to an .exe that does understand".

It would be the responsibility of the AutoHotkey script writer to select the .exe that understands the syntax of that "other" scripting language.


OtherScriptStart,

; Perl Syntax (for example)

OtherScriptEnd,

OtherScriptRun, ;It is at this point that the AutoHotkey script writer must decide on the correct .exe to run his/her above commands. Getting this correct would be their responsibility.

The responsibility of "backwards compatibility" would be that of the individual AutoHotkey script writer and the makers of the script language.

In general, future upgrades of cscript.exe or wscript.exe would have the same name so "OtherScriptRun" would not have a problem with that and the makers of the script language, say Microsoft for example, would be reponsible for "syntax backwards compatibility".


2. It would not only require 'standard' compatibility, but - to make it smooth - compatibility with 'all' different packages/builds of the script interpreters, which - in some cases - can be quite many.


The proposed AutoHotkey syntax is just for the purpose of "passing commands in that other scripting language". AutoHotkey, itself, would not understand the syntax nor care.

The AutoHotkey script writer using the "other script language" would need to understand what they are writing and .exe they are passing the syntax to needs to understand.

The proposed AutoHotkey command/syntax, is simply making such "passing" easier than it is now and perhaps without the need to use temp file, many steps, or confusing syntax.

3. It would distract the focus from AHK itself, ready-made other-language scripts would be incorporated eventually in the - to be - standard library, which would make it even more difficult to maintain


AutoHotkey as a language will actually be as "pure" as ever, with such functionality. This type of functionality would allow the development of the AutoHotkey language to be based on "ease of use and understanding".

There would not be any rush to "twist" the AutoHotkey language to provide some "power feature", like what is done with AutoIt.

Also, remember that this "OtherScript" type functionality has been used in a number of other automation languages. For example:

Macro Scheduler ( http://www.mjtnet.com/ )

Aldos Macro Recorder ( http://www.aldostools.com/macro.html )

etc....

The above allows the use of VBScript to help supplement the "power" of their automation languages for those that need it, but at the same time allows "their own automation language" to maintain its "easy of use".

The other aspect of your point, was kind of like... the future AutoHotkey standard library would get "corrupted" with "impure syntax".

Well, would not AutoHotkey as some point adopt new syntax? Eventually, AutoHotkey is going to add new commands and those "future" standard libraries are going to use those commands and there are going to be "backwards compatibility issues".

The other aspect of that is that Chris and/or his AutoHotkey team would decide what would ge accepted and become an AutoHotkey library. They just as easily could say, "no non-AutoHotkey syntax allowed".

The proposed "OtherScript" syntax, is more or less, a special purpose "helper" for AutoHotkey users.

Remember, you can already "kind of" use "other scripting language syntax now" but its just "twisted", has multiple steps, and unspecific syntax. Adopting a special "OtherScript" command, is just acknowledging the obvious of what can be done and making it a "smooth" and "easy to use" process in AutoHotkey.

4. Scripts would emerge that would require a mixture of different scripts and their interpreters, not only AHK, which - fortunately - can work almost independent. Again, soon one would have serious compatibility problems with different versions of interpreters used etcet. (see 1.). Users would no longer have the comfort of knowing it is AHK, so it runs :wink:


But you would know what is AutoHotkey and what is not.

For instance, at the present time AutoHotkey can not do ActiveX/COM/OLE. Creating a script that uses the "OtherScript" command that allows a AutoHotkey script to do ActiveX/COM/OLE functions is clearly beyond AutoHotkey language capacity (at present).

We could make an AutoHotkey script that "does" ActiveX/COM/OLE by using VBScript commands right now. Though we would do this by using temp files, multiple steps, and unspecific/twisted syntax. Myself and others are just saying, "Hey, lets make this present ability easy to use (or just easier), easy to understand, and make the syntax used clearer."

Also, powerful user contributed scripts that can help AutoHotkey people do useful things is a "good thing". There has been many cases of AutoHotkey users talking and using Javascript, VBScript, AutoIt , etc.... Its a matter of using something that will help get the job done. The "OtherScript" syntax is not any different.

Furthermore, the "OtherScript" type syntax/command, will help AutoHotkey stay "pure" not the other way around.

corrupt
  • Members
  • 2558 posts
  • Last active: Nov 01 2014 03:23 PM
  • Joined: 29 Dec 2004

Volunteers? :)

I'm interested :) . I will likely not have enough free time available to contribute full-time though so please don't let my interest discourage anyone else from volunteering :) .

webber
  • Members
  • 129 posts
  • Last active: Aug 13 2011 06:45 PM
  • Joined: 25 Aug 2005

is there anything wrong with this?


That methodology doesn't always work. AHK gets confused with the syntax of some vbscript code and won't process the file.

AHK should be configured to separate out the vbscript code with some type of delimiter as mentioned earlier so it will ignore the vbscript code for syntax.
________
Wilmington assembly

not-logged-in-daonlyfreez
  • Guests
  • Last active:
  • Joined: --
Then I would propose an extra option to set a variable without AHK interfering with the syntax, so that escaping special characters will no longer be necessary.

Something like this (pseudocode)?

readyToUseVBScript := NoEsc(VBScript,
(
Here some characters that normally would need escaping...
))

; or

readyToUseHTML := NoEsc(HTML,
(
Here some characters that normally would need escaping...
))

And yer can count me in as a volunteer too (though my time is limited too)

I will investigate further in smoothening calling and getting data back from other scripting languages - like VBScript - with AHK (and probably CMDRet) as it is now...

not-logged-in-daonlyfreez
  • Guests
  • Last active:
  • Joined: --
It seems, since VBScript can do SendMessage, it is probably possible to run a VBScript (thru a temp file sofar), and use Post/SendMessage to send the wanted variables back to the calling AHK Script, and have OnMessage handlers to process the result...

Another option is passing arguments on the command line, however, this is less useable...

I'll post my results a.s.a.p.

daonlyfreez
  • Members
  • 995 posts
  • Last active: Jan 23 2013 08:16 AM
  • Joined: 16 Mar 2005
Ok, I've not found a method yet to make a VBScript running without using a file, and I'll try to login more... :p
Posted Image mirror 1mirror 2mirror 3ahk4.me • PM or Posted Image

AHKnow
  • Members
  • 121 posts
  • Last active: May 17 2009 09:11 PM
  • Joined: 03 Jul 2004
Thanks guys, I greatly appreciate everyone that is helping on this.

corrupt
  • Members
  • 2558 posts
  • Last active: Nov 01 2014 03:23 PM
  • Joined: 29 Dec 2004
I might have an option soon...