54 replies to this topic

[AHKnow]

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

Chris, I'm a bit confused on your intentions. This old request is not the same as asking for native activex/com/ole support in AutoHotkey. This request, presently, is more about modifying Fileappend to add additional functionality

This requet is a year old (after all) and some other users have expressed interest. Like WinLIRC seems to have been rubber stamped right away... Many parts of the new command request (fileappend, run, runwait) already exists, it would mainly be putting it together for a more specific purpose of supporting other scripting languages.

It would also be a chance todo something different fom AutoIt, but also support a means to provide activex/com/ole, .net, and so much more. I think such a command would be huge for Autohotkey.

[Chris]

Like WinLIRC seems to have been rubber stamped right away...

Anything central to the hotkey mission automatically gets a very high priority as long as it's feasible and the code isn't too large. Even if it weren't for that, the ability to use hand-held remotes has been suggested several times over the past year.

By contrast, doing anything with VBScript and others is a lower priority because:
1) The target audience for AutoHotkey's missions are not programmers. I realize that you don't have to be a programmer to use something like VBScript, but you have to be close.

2) A lack of experience on my part, which means a steeper learning curve and more chance of making design mistakes.

I'm a bit confused on your intentions.

I think the misunderstanding is on my part: I didn't see a large benefit to your proposal because it doesn't provide true integration. It seemed to me that the ability to get data into and out of an external script was too limited to justify giving it a high priority.

However, I'd welcome more brainstorming about how such a feature would work and why the benefits are significantly better than FileAppend+Run. It would be ideal (but probably too much to expect) if someone would make a proof-of-concept in the form of a callable function that creates and executes an external script, and retrieves some data from it. That kind of thing can really sell an idea, not to mention that it might become the foundation of a complete feature set available as part of the planned "standard library" distributed with the program.

[AHKnow]

Chris, I do very much understand your position on this, but I do feel that this added functionality to AutoHotkey would be worth it.

There have been many posts where users have requested or find ways to get AutoHotkey to work with other scripting languages.

Examples:

http://www.autohotke... ... ighlight=0 (with Javascript)

http://www.autohotke... ... ighlight=0 (with Perl)

http://www.autohotke... ... ighlight=0 (with Perl)

Yes, Fileappend+Run with temp files can be used, but I think the advantage of a separate syntax especially for this would make such a feature easier to use, understand, and easier to adapt in the future. Also, this syntax could possible eliminate the intermediate step of temp files, if so desired, to increase the speed of execution and increase security.

If it is your intent to add things such as ActiveX/OLE/COM, would not this be already what VBScript and AutoIt are offering?

Users could just as easily be using the proposed syntax and/or fileappend to add a few lines of VBScript to get the ActiveX/OLE/COM that they need. Futhermore, this method goes way beyond that, as you can add many different types of commands.

[Chris]

I think the advantage of a separate syntax especially for this would make such a feature easier to use, understand, and easier to adapt in the future.

I wanted to avoid adding a feature that would become obsolete if Active Scripting or some similar integrated solution were ever added.

Also, this syntax could possible eliminate the intermediate step of temp files

Assuming you don't know for sure that this would work -- or exactly how to do it for each of the desired external languages -- I'd like to see more details that: 1) show it would work; and 2) show the mechanics behind it. I've already made a note to research it myself in case no one else does.

If it is your intent to add things such as ActiveX/OLE/COM, would not this be already what VBScript and AutoIt are offering?

If you're referring to the decision not to create a DLL version of AutoHotkey, I think Active Scripting/OLE/COM are different. This is because the DLL is an entirely separate product for programmers, for which AutoIt already has a solution. But Active Scripting/OLE/COM would provide new functionality to existing users of AutoHotkey.

[Nemroth]

I think that, if it is technically possible (and I think it is, but may be I'm wrong), it is better to have VBScript (or an alternative) embedded in an AHK script, so if the script is compiled it will be "auto sufficent", say the integrated VBScript script will be executed as it was a "native" AHK script (I hope I am understandable and that it is possible !!!).

If it is your intent to add things such as ActiveX/OLE/COM, would not this be already what VBScript and AutoIt are offering?

May be it is usefull to say that :

1) Concerning AutoIt, the ActiveX DLL brings the ability to other languages to use AutoIt commands, witch is probably of a very little use for the AHK users, as the two softwares have many common points.
I think that the AutoIt DLL don't give the ability (may be I'm wrong) to AutoIt programmers to call external (script) languages, nor to execute internally VBScript or VBA code, for example.
But may be this way can be studied, as it can be a good thing to be able to call AHK commands from VBScript or others programming environements witch supports ActiveX/COM ???

2) Concerning VBScript, it permits to use ActiveX/OLE/COM, so for example to execute VBA code, and so to control external apps like MS Office or other ActiveX/COM compliant apps, and I think it is one of the most important reasons (in my mind) to use VBScript embedded in AHK scripts : to be able to have "total" control over Excel and Word (standard softwares), for instance, from AHK.
There are a lot of VBA code examples to be able to develop automation procedures for Excel and Word.
It would give the possibility to send variables values to fill a word document/form or an Excel spreedsheet, for example, even if it is closed (ActiveX/COM/ADO) !!!
For example :
How To Use ADO with Excel Data from Visual Basic or VBA
Or in the french Web site of frederic sigonneau, button "VBA Excel" and then the "ADO et techniques de travail avec des classeurs fermés" link (ADO and techniques to work with closed workbooks), you can see (there are some example in english) how to read and write closed Excel workbooks with VBA and ADO.
There a probably a lot of other examples in the usenet group "microsoft.public.excel.programming", in witch you can search with Google Groups
Of course we can already control Word or Excel from AHK, but the possibilities of control would be very much important and powerfull this way.
So, Chris, if you can (and want of course) integrate VBScript to AHK, may be you would not "have to" develop an ActiveX/COM/ADO interface, as it is already built in VBScript (may be I'm wrong, I don't know).

But in any case, which was already carried out in AHK is superb !!! A extraordinary work !!! Thanks Chris for the beautifull job.

Edit :

1) The target audience for AutoHotkey's missions are not programmers. I realize that you don't have to be a programmer to use something like VBScript, but you have to be close.

May be, but a forum can be the ideal place to share knowledge... When I see a Lazslo's script, I know there will be some (a lot of !!!) time before I can understand how it works, but it's the way to progress.

2) A lack of experience on my part, which means a steeper learning curve and more chance of making design mistakes.

A way for you to progress !!!! And (at least for me), there isn't any emergency (Aren't we in the "Wish List" forum, and not in the "Then, Chris, you can't go more quickly ?" forum ? (Joke ... ))

[daonlyfreez]

I truly hope direct support for VBScript will never come true, for that is exactly the reason I left AutoIt, or better, the syntax change into VBScriptish scripting.

You can FileInstall a VBScript, or any script/program. If you are fond on Basic, you have enough choices already. I am really discouraging this 'let's support Basic' thing, I've seen it before :cry:

And I don't think we need full support for ActiveX/COM etcet. (all them 'yummy'? Microsoft thingies) either.

See also this discussion about support for .Net/C# (again, Microsoft exclusives)

I'm for supporting the Open Source packages out there, they are equally good, or maybe even better then their Microsoft equivalents. The further AHK stays away from dependancy on Microsoft, and the more it uses Open Source available, the closer it is to porting to other platforms 8)

[Nemroth]

I truly hope direct support for VBScript will never come true, for that is exactly the reason I left AutoIt, or better, the syntax change into VBScriptish scripting.

I hope it will be, but I don't see why VBScript integration would lead to a "VBScriptish scripting". It's "just" the ability to make VBScript run within an AHK script (if it could work in compiled form it would be better) : the AHK syntax would remain the same and the guy who don't want to use VBScript would not have to do, of course...

And I don't think we need full support for ActiveX/COM etcet. (all them 'yummy'? Microsoft thingies) either.

No problem it's your opinion and I am agree with it. Except for a detail : if you use AHK at home, you don't care about M$Beurk soft and I am (almost) agree with you. MS softs are far too expansive (also the OS), very often bugged (because of the speed of developement : one version every 2 years make it difficult to have bug-free softs ?). On its hand, Open Office is very impresive.
But for my point of vue, I have to consider the fact that the most of my AHK programming is for the work (for me at work). At the firm, I said that Open Office is better than MS, and at no cost, but the boss said : "I don't care, MS Office is a standard product and we use it because all the firms with witch we work use it too". So, and it's only my point of vue, I'd like to see VBScript support in AHK, and, if usefull (if the implementation fo VBScript is sufficent to manage it or not) ActiveX/COM/ADO (all rubish, OK) support in AHK. I can ensure you that if Chris can (and wants to) implement them, nobody will oblige you to use them if you don't wish.

I'm for supporting the Open Source packages out there, they are equally good, or maybe even better then their Microsoft equivalents. The further AHK stays away from dependancy on Microsoft, and the more it uses Open Source available, the closer it is to porting to other platforms 8)

I'm 100% OK with that, but at work it is unfortunately not realistic.

Edit : I forgot !

The further AHK stays away from dependancy on Microsoft, and the more it uses Open Source available, the closer it is to porting to other platforms 8)

Other plaforms ? So if you like Open Source I can't think anything else than Linux... May be, but AHK becomes dangerously and increasingly close to Windows (DllCall, OnMessage, SendMessage, ...) It becomes so close that it's portability to others platforms is probably very difficult... AHK seems to be already very dependent on Windows ... from Microsoft...

[AHKnow]

I think the anti-Microsoft thinking will only hurt AutoHotkey. The reality is:

1. AutoHotkey works on Microsoft operating systems.

If you/we/AutoHotkey was really anti-Microsoft, then why develop on the platform in the first place? Why is AutoHotkey not on the Linux platform?

2. Many AutoHotkey users are using numerous Microsoft products. MS Office, Word, Excel, Internet Explorer, etc...

The "door" to more effectively use such products is VBSscript and Visual Basic for Applications. Which, by the way, Microsoft is making it clear by its actions that it will eventually transition those to VB.NET or C#.

Going beyond the Microsoft issue, supporting such a syntax would mean more than just the benefit of Activex/COM/OLE. Why?

1. Even if AutoHotkey developed its own "flavor" of ActiveX/COM/OLE, it will undoubtedly be something resembling ActiveX/COM/OLE in VBScript and VBA.

2. A modification to the Fileappend syntax or a new syntax for the purpose of supporting other scripts using cscript, wscript, and some others will allow the integration of these other scripting languages with AutoHotkey, if the user needs this functionality.

It will in effect be the equal of an AutoItX.dll, in terms of allowing AutoHotkey to be able to work with other languages.

The huge difference being is that instead of having to be an expert in some other language and make use of the AutoItX.dll for automation, an AutoHotkey user can stay an expert in AutoHotkey and just know little bits of another language to do something.

3. Because of the multi-functionality of such a syntax, I don't think that it will be old or unnecessary, even if AutoHotkey develops ActiveX/COM/OLE. People could still use such syntax for Perl, .NET scripting, etc... It would be providing extra options to do things.

[AHKnow]

I truly hope direct support for VBScript will never come true, for that is exactly the reason I left AutoIt, or better, the syntax change into VBScriptish scripting.

But that is the whole beauty of having this kind of command. The core language of AutoHotkey is not "forced" to modify itself into becoming some weird form of Basic like AutoIt has become.

I also like the easy to use, understand, and read scripting language of AutoHotkey.

If an AutoHotkey user needs a little something "extra", he could use an "OtherScript" command to do what they need.

Such an "OtherScript" command means that AutoHotkey can focus on "ease of use" type changes. If an AutoHotkey user wants to do something "different" than they simply write out the VBScript, Jscript, Perl, .NET etc... commands and then have the "OtherScript" command run it.

Also the use of the other scripting languages will be seamless. The AutoHotkey would purrrr along, then run those other scripting language commands, and then go back to cruising along again.

The AutoHotkey user can have all of this functionality in ONE script. He could even mix Perl, with VBScript, with .NET if they wanted to.

The bits of other scripting languages would be called upon when the AutoHotkey users needs to do something that AutoHotkey can not presently do.

[Nemroth]

Just a little precision about what I think.
I think that a good thing to have better control over MS Office apps would be to have the ability to integrate, if possible, VBScript or WSH scripts in AHK scripts, so to be able to run such scripts code in a compiled AHK script (I don't know if it is possible).

The goal for me would be to be able to use the ActriveX/COM/ADO capabilities of these script languages to increase the possibilites of automation of the MS suite and to be able to run VBA (like ?) code "inside" an AHK script, even compiled.
If the goal is to be able to call an external script file and to run it, probably that can be done by just calling a certain command line or a DLL (like with Perl integration in Calling Perl from AHK topic), and for numerous sorts of script languages (?).

[AHKnow]

To clarify things...

When I mention "OtherScript command", I mean to be able to run VBScript, JScript, etc... inside of AutoHotkey.

Presently, a way to do this would be to use "Fileappend" and "Run", and I gave an example of this on an earlier post.

I would like to see a new and specific command to support VBScript and other languages that use wscript, cscript, and if possible .NET scripting languages OR modification of Fileappend.

I would like to see the "OtherScript command" or "Fileappend" not have to use .tmp files like it is presently using, when you are using syntax from another scripting language. One method under consideration is the use of piping >, for example test.vbs > cscript.exe, to accomplish this so that you don't need temp files.

As an example, AutoHotkey would copy the VBScript syntax (or other script) to the clipboard and then pipe it > to a specified .exe like cscript.exe or whatever.

I was hoping that AutoHotkey could provide support for VBScript, and other scripting languages like Perl, by using the "OtherScript" command or modified "Fileappend" command.

I have proposed that the new "Otherscript command" be composed of, "Fileappend" + "Clipboard"+">(piping)" + "Run" , combined.

But, there might be another method to do this. If anybody knows than feel free to jump in...

Basically, Nemroth, I'm with you on this.

[Nemroth]

When I say "Integrate" I'd like to see something like this, if it is possible :

Send, Hello

; Others AHK script commands/instructions

<VBS START>

----> VBScript (or other...) script commands/instructions

<VBS END>

Send, How are you ?

...

So I prefer to see AHK to be able to execute internally VBScripts scripts (by calling an external executable to interpret the VBScript commands (send why not by pipes)). I'd like to see the VBScript source code (or other) embedded in the AHK source code, like JavaScript scripts are embedded in HTML sources...
So in my mind the VBScript (or other...) would be able to be compiled with the AHK source code, even "in clear", as AHK exes are UPXed (may be it isn't feasable) ...
For me, the use of FileAppend (or similar) would be the same as calling an external and already existing .vbs file and pipe it to the VBScript executable.
But may be a VBScript can't be executed if it isn't in an external .vbs file, or may be it is impossible to include VBScript source code in an AHK source code, in which case the ability to call and execute an external .vbs file (that already exists or witch is created by an AHK script, it doesn't matter) would be sufficent for me.

[AHKnow]

From- http://www.wilsonmar.com/1wsh.htm (good little article)

A bit more- http://msdn.microsof...antagesOfWs.asp

The reason why I suggested to try to implement support for the various scripting languages that Microsoft Windows can support with cscript/wscript is based on how easy, I think, it would be to implement in AutoHotkey.

OtherScript command = Fileappend + Clipboard + > (piping) + Run, combination already exists as parts of other commands. It may be a matter of borrowing bits of code from the other commands to put it together. The other alternative would be to just modify the Fileappend command in the same manner.

Note 1, examples:

OtherScript, , (maybe some other options),
(

Whatever the scripting language

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

Or

OtherScriptStart,,,(maybe some other options)

;Whatever scripting language...

OtherScriptEnd

OtherScriptRun,,,(with other options)


Note 2- WSH has Stdin, Stdout, and Stderr support

As you can see from the picture, wscript.exe and cscript.exe are close to the GUI and OS and do what we would want. AutoHotkey, could just help make it easier to add commands from those other Microsoft supported scripting languages for those AutoHotkey people that need it.

This approach would also help get ActiveX/COM/OLE closer to AutoHotkey, in addition to all the other things the different scripting languages can bring. I also want to emphasize that this would do more than just make it easier to do ActiveX/COM/OLE in AutoHotkey.

Another point, is that there is a lot of talk that Microsoft is going to orphan VBScript and VBA (though this may be some to many years from now) in favor of VB.NET, JScript (which is close to the International standard of JavaScript), JScript.NET, and C#. The approach that I mentioned would allow you to not have to worry and be able to keep using many different scripting and .NET scripting languages with AutoHotkey.

Note 3- For the Anti-Microsoft people... The vast majority of computer users are using Windows and Microsoft Office applications. Microsoft is not going to give up supporting various scripting languages to work with Windows and MS Office.

If somebody has a better way to implement this type of ability in AutoHotkey than feel free to suggest it.

And Nemroth, I'm with you on this.

[Chris]

OtherScript command = Fileappend + Clipboard + > (piping) + Run
...
(maybe send to "Clipboard" and/or "tmp" file), cscript.exe/wscript.exe (whatever .exe used to run other script).

It sounds promising. Since I know nothing about wscript/cscript, it would help to see a proof of concept of this. Here is one framework that could be a starting point:

Script =
(
... put the lines of the script to be run here...
line 2
line 3
)

result := OtherScript(Script)  ; Launch the script above.
MsgBox %result%

OtherScript(ScriptToRun)
{
; Put ScriptToRun into temp file or clipboard, or pipe it to the external interpreter.
; Launch script with wscript/cscript.
; Maybe use cmdret to get output from the script by connecting to its stdout?
}

Since I have no experience with WSH, VBScript, etc., perhaps someone else can look at this and try it out. It would be ideal to see a prototype that demonstrates exactly how piping and/or the clipboard could make things more seamless.

Thanks.

[Nemroth]

@AHKnow :

Note 1, examples:

OtherScript, , (maybe some other options),
(

Whatever the scripting language

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

Or

OtherScriptStart,,,(maybe some other options)

;Whatever scripting language...

OtherScriptEnd

OtherScriptRun,,,(with other options)

Seems to be good suggestions, close to what I'd like to see in AHK. I'll read carefully the infos in the link you provide.

@Chris :
May be your proposition can work. To see what to put in the function.