68 replies to this topic

[erictheturtle]

Include VBScript or JScript code directly in your Autohotkey program!
No temporary files. Full and easy access to COM.

Checkout the official homepage for the latest version, (old) demos, change log, and documentation:
<!-- m -->https://ahknet.autohotkey.com/~easycom<!-- m -->

Note: ws4ahk is made for Autohotkey Basic. It may work with Autohotkey_L, but it is not supported.
------------------------------------
This topic was split off from the old topic "EasyCOM.dll" development.
Original post content is below.
------------------------------------

I've been thinking long and hard about using Microsoft Scripting Control to provide easy COM usage to AHK, and the more I have, the more it became the ultimate choice--far better than anything I could develop myself.

Pros
* Automatic objct management (objects are automatically deallocated--no memory leaks!)
* Able to use either VBScript or JScript to write COM related code
* ByRef argument handling is all taken care of
* Almost all VARIANT handling is taken care of
* Can very easily write compound COM statements (e.g. objExcel.Workbooks.Add().Sheets(1).Cells(1,1).Value = 50)
* There's no need for an extra dll (like EasyCOM.dll). It can be done entirely in AHK.
* Much more easily implemented!

The ONLY disadvantage with using Microsoft Scripting Control is that there may be some computers that do not have it installed (but probably not very many). HOWEVER, not only is it available to download from Microsoft and very easily installed, but thanks to that WS_CreateObjectFromDll() function, it doesn't even have to be installed! If a computer doesn't have Microsoft Scripting Control installed, you just need to supply the msscript.ocx file in the same folder as your script, and it will still work perfectly. No need to register the OCX. Your script remains completely portable!

Once this is better tested and found to really work, I think you can agree that there is no reason to continue making the not-so-easy EasyCOM.dll anymore. This is by far a better solution.

[Sean]

but thanks to that CreateObjectFromDll() function, it doesn't even have to be installed!

Hmm... Have you tested with this DllGetClassObject?
Actually MS discourages to call it directly. It's called always indirectly, through CoGetClassObject, probably the most important single function in COM.
Anyway, thanks for this very interesting idea, and I'm tempted to use with it CoLoadLibrary instead of LoadLibrary.

[erictheturtle]

It's time for another hair-brained API scheme...

I've been working on using Microsoft Scripting Control for COM, and so far things seem to be ok. I'm not quite sure what to call it, so for now I've named it "EasyScript". The #Include file is looking to be a beefy 1000 lines. Right now the API looks something like this:

LoadEasyScript(Language)
UnloadEasyScript()

ES_Exec(VB or JS string) ; for no return value
ES_Eval(VB or JS string) ; for return value

ES_AddDispObject(IDispatchPtr)
ES_AddObject(ClsId, Name)
ES_AddObjectFromDll(ClsId, Name)

VBStr(String)
JSStr(String)

ES_AddObject() is useful for creating objects by ClassId, since you can't do that in VBScript/JScript. ES_AddObjectFromDll() is thrown in just because it's easy, but I can't imagine anyone actually using it. ES_AddDispObject() is useful for putting ActiveX controls under the care of VBScript/JScript (assuming that works).

VBStr() and JSStr() wrap strings in quote and escapes any quotes in the actual string.

Here's a short usage example

sFile := "C:\WINDOWS"
ES_Exec("Set oFSO = CreateObject('Scripting.FileSystemObject')")
IsFolder := ES_Eval( "oFSO.FolderExists(" VBStr(sFile) ")" )
; IsFolder = 1
ES_Exec("Set ByRefObj = CreateObject('Object.With.Byref.Param')")
ES_Exec("ByRefObj.ByRefMethod ", ByRefArg )

As you can see I'm using single quotes (') inside the strings. This isn't normally available in VBScript, but to make things easier I may try to allow for it. No guarantee it will end up in a final version.

ByRef arguments can be passed as variables between strings. After the call, the byref variable will be updated with the new value.

I still haven't looked into how to handle script errors.

All this may be too much encapsulation however. It may be better to just expose the Scripting Control methods and let the scripters write VBScript/JScript however they like.

I dunno, I'm still working on it. I'm curious what others think.


Also, It occurred to me that while this "EasyScript" API is handy for the COM basics, it still lacks support for creating ActiveX controls and handling COM Events. I haven't looked too closely at Sean's ActiveX control related scripts, so maybe those will be fine for handling that. I also haven't looked at COM event handling.

But I think those things are better suited for separate #Includes, and the separate APIs can be written to interface with each other.

In any case, I may have bitten off more than I can chew with all this COM stuff, so I'm going to have to pass on delving into COM Events, at least for now.

Hmm... Have you tested with this DllGetClassObject?

Yup, and it has worked flawlessly so far.

I'm tempted to use with it CoLoadLibrary instead of LoadLibrary.

Ah, you really are quite a COM master. I didn't even know about that function. I gave it a try, but it wasn't working in my tests. Have you had any luck using it?

[Sean]

I didn't even know about that function. I gave it a try, but it wasn't working in my tests. Have you had any luck using it?

Yes, I used it successfully to test DllGetClassObject which worked fine.
One thing you might miss is that you have to use always Unicode string with it.

PS. BTW, no real need to use it. Looks like exactly the same behavior with LoadLibrary.

[erictheturtle]

One thing you might miss is that you have to use always Unicode string with it.

Ah yes, I missed the need for a Unicode path--that got it working, thanks.

PS. BTW, no real need to use it. Looks like exactly the same behavior with LoadLibrary.

Is it possible that the library is automatically unloaded when CoUninitialize() is called? It would be really nice if it was.

I think that I'd like to be able to use VBScript instructions internally in AHK, especially those relative to COM .... But I'd like to be able to execute a full VBScript script (not line by line...) and to get back the result

Thanks for the feedback Dashboard. It does seem like this is the best approach.

The functions haven't really changed, but their parameters have. Plus I thought that adding a simple 'printf' style syntax would make the code much easier to write (no need for lots of ugly double quotes and string concatenation).

vbwmp := "oWMP"
If (!ES_Exec("Set %v = CreateObject(%s)", vbwmp, "WMPlayer.OCX"))
	Msgbox % ES_Error()
If (!ES_Eval(pwmp, vbwmp))
	Msgbox % ES_Error()

%v inserts the value, and %s inserts the value wrapped in quotes, with special characters escaped.

ES_Eval() will return the value of most script variables. I don't think I'll implement getting return values for Dates and Currency variables, and especially not for Arrays (you should write a script function to convert the array to something you can use before returning it).

You can create an object in the script, put that same object into a COM control, and then control from the script.

DEdit := "DEdit"
If (!ES_Exec("Set %v = CreateObject(%s)", DEdit, "DhtmlEdit.DhtmlEdit"))
		Msgbox % ES_Error()
If (!ES_Eval(ppvDEdit, "DEdit"))
		Msgbox % ES_Error()
		
hContainerCtrl := AtlAxCreateContainer(hWnd, 0, 25, 800, 575) 
AtlAxAttachControl(ppvDEdit, hContainerCtrl)

DE_LoadUrl(DEdit, "http://www.autohotkey.com")

DE_LoadUrl(sDhtmlEdit, url)
{
	If (!ES_Exec("%v.LoadUrl %s", sDhtmlEdit, url))
		Msgbox % ES_Error()
}

You could alternately create an object using one of the EasyScript's or Sean's create/get object functions, then pass the object into the script (via AddObject) to be controlled there.

You can always execute more than one line of code at a time.

DE_BrowseMode(sDHtmlEdit)
{
	sCode = 
(
If `%v.Browsemode = 0 Then
 `%v.Browsemode = 1
Else
 `%v.Browsemode = 0
End If
)
	If (!ES_Exec(sCode, sDHtmlEdit, sDHtmlEdit, sDHtmlEdit))
		Msgbox % ES_Error()
}

This allows you to add functions inside your script. Heck, you could even create classes inside the script, instantiate it, and return it for use in AHK. I haven't pondered just what this could mean. I wonder if it would help with COM event handling at all...?

But speaking of event handling: There is the VBScript GetRef() function which may be used to insert a script call-back function for objects that allow it. These are usually the "OnClick" kind of functions. From what I've seen, it's still limited to a subset of the available object events. There are many other events I can't get access to.


The code is currently working, but I'm still running tests.

I'm also pondering how this script and Sean's scripts should play together. EasyScript covers everything that his CoHelper.ahk does, but if you want to utilize COM controls then we'd need code from IEControl.ahk, which requires CoHelper.ahk...

So I'm thinking I should just include the core functions from IEControl.ahk in EasyScript. This will keep those functions available to script-writers. I hope no one minds if I rename some of them and maybe change their API a bit. My target script-writer is familiar with VB and has never seen Co* functions or Atl* functions, and my goal is that they never have to.

It is quite clear that EasyScript will be much larger than Sean's scripts, both in code size and memory usage. It will also be slower. BUT it will be easy (I hope). :)

[Chris]

Erictheturtle, this is a really provocative topic. I hope you continue to work on it because it would add a lot of often-requested functionality (e.g. embedding VBScript and other scripting languages).

Thanks!

[erictheturtle]

Thanks Chris.

I've been working on "EasyScript" this whole time. Seems like every time I look at the code, there are a dozen things I need to add/change/remove/improve. Even just this morning I made an improvement to the API.

The code has grown into a massive 1500 lines, although it is worth noting that a few hundred of those lines are for comments and error checking.

This script contains a ton of error checking and reporting. While it is really nice for development, not everyone may want to have that extra bulk in their released code. Plus, it seems like most are content with Sean's scripts which have no error checking. So I've designed the EasyScript code so the error checking is easily removed via a simple AHK script (not made yet).

Even so, nothing will ever be as lean and mean as Sean's scripts.


There's still a bunch of things I want to clean up in the script. I would like to make the error handling more consistent between the different parts. Plus there is still more error checking to be added. But the script is fully functional.

So here's the first version: v0.01 beta (21Jul2007) I hope the API doesn't change anymore, but no promises.

I didn't think "EasyScript" was such a good name for it. The most accurate might be "Embedded Microsoft Windows Scripting Host for Autohotkey", but that's just silly. I'm leaning toward "Windows Scripting for AHK", abbreviated as WS4AHK or simply WS. A possible alternative is "COMscript", which emphasis its ability to access COM. Anyone have any thoughts/preferences?

Download

Here is also an example script. It's a conversion of ABCYourWay's DHTML edit program to use this new WS4AHK script.

WS_DEControl.ahk
WS_DEdemo.ahk


When I get around to it, I'll post a fresh new forum topic and include a link to API documentation.

[erictheturtle]

Thanks for trying out the WS script ABCyourway. You've found a bug I'll have to try to fix later.

There are a few things you need to correct.

DE_JustifyLeft([color=red]s[/color]DHtmlEdit)    ;

DE_JustifyCenter([color=red]s[/color]DHtmlEdit)    ;

DE_JustifyRight([color=red]s[/color]DHtmlEdit)    ;

This same correction needs to be made on these functions as well.
DE_SelectAll
DE_Paste
DE_Properties
DE_UnDo
DE_ReDo
DE_FindText
DE_Delete
DE_Cut
DE_COPY
DE_OrderList
DE_UnorderList

I renamed the variable from pDHtmlEdit to sDHtmlEdit because you need to pass in the name of the object in the scripting environment (which is a string).

DE_InsertTable([color=red]sDhtmlEdit,[/color] numrows, numcols)
{
  [color=red]If (![/color]WS_Exec("Set [color=red]tParam[/color] = CreateObject(%s)", "DEInsertTableParam.DEInsertTableParam")[color=red])[/color]
     [color=red]Msgbox % A_LineFile ":" ErrorLevel[/color]
  ; create a table object
  [color=red]If (![/color]WS_Exec("tParam.NumRows = %v", numrows)[color=red])[/color] ; -> set the table property.
     [color=red]Msgbox % A_LineFile ":" ErrorLevel[/color]
  [color=red]If (![/color]WS_Exec("tParam.NumCols = %v", numcols)[color=red])[/color]
     [color=red]Msgbox % A_LineFile ":" ErrorLevel[/color]
  ;WS_Exec("Set tParam.TableAttrs = 100%")
  
  global DECMD_INSERTTABLE, OLECMDEXECOPT_DODEFAULT
  If (!WS_Exec(sDhtmlEdit ".ExecCommand %v, %v, [color=red]tParam[/color]"
              , DECMD_INSERTTABLE
                , OLECMDEXECOPT_DODEFAULT))
    Msgbox % A_LineFile ":" ErrorLevel
}

In the GetSelection() function, you seem to be mixing AHK and scripting code, and using %s when you should be using %v. It might be easiest to just change all that code into scripting code. I'll post a fixed function later when I have time.

Since this WS version of the script is a translation from your original code, I kept most of the code structure the same. However, since there is only one DHtml edit control, much of the code could be simplified by removing the sDhtmlEdit variable and just refer to the object's name directly in the scripting code. I'll post a rewrite later for an example.

[erictheturtle]

This GetSelection() function should work:

GetSelection(sDHtmlEdit)
{
	sVBCode =
	(
		SelType = `%v.DOM.Selection.Type
		If SelType = "Text" Then
			SelectedText = `%v.DOM.Selection.CreateRange().HtmlText
		Else
			SelectedText = ""
		End If
	)

	; Execute the VB code
	If (!WS_Exec(sVBCode, sDHtmlEdit, sDHtmlEdit))
		Msgbox % A_LineFile ":" ErrorLevel

	; The variable "SelectedText" in the scripting environment holds the
	; selected text. This gets the value out of the scripting environment.
	If (!WS_Eval(SelectedText, "SelectedText"))
		Msgbox % A_LineFile ":" ErrorLevel
	
	Return SelectedText
}

If you include this, your script should fully work.


I've updated ws4ahk.ahk to fix the bug (now v0.02). See the new very unglamorous site.

I also uploaded new variations of WS_DEControl2.ahk and WS_DEDemo2.ahk that removes the need to pass the object name into every function.

[Chris]

I hope you don't mind, but I've split this topic off from your topic "EasyCOM.dll" development. Hopefully it will make things easier. Feel free to revise the topmost post of this topic as you see fit.

I've been working on "EasyScript" this whole time.

I've reviewed your code and tried the demo. It's all very impressive, and it's obvious you put a lot of thought into the interface. Also, it's great that you included clear, concise documentation at the top of the file.

I didn't think "EasyScript" was such a good name for it. The most accurate might be "Embedded Microsoft Windows Scripting Host for Autohotkey", but that's just silly. I'm leaning toward "Windows Scripting for AHK", abbreviated as WS4AHK or simply WS. A possible alternative is "COMscript", which emphasis its ability to access COM. Anyone have any thoughts/preferences?

All the candidates have some appeal, but I think I prefer "Windows Scripting for AHK" for its greater accuracy. Another idea is "Windows Scripting and COM (WS+COM)" because the "for AHK" part might not add much value in the contexts it's likely to be mentioned in.

Once you decide on a name, feel free to rename your homepage from ~easycom to the new name (unless it's too much trouble). I can update the links throughout the forum.

Even so, nothing will ever be as lean and mean as Sean's scripts.

Since I still know so little about COM, I'd like to rely on you and Sean for the following (to the extent you have time):

1) Can/should COM Helper be merged into this Windows Scripting API in a way that gives the best of both worlds? (Maybe that would cause too many compromises.)

2) I realize that you intend to improve the API and documentation (as time permits). When you're ready, perhaps you or someone else can update the following wiki page (and/or make a new page):
<!-- m -->https://ahknet.autoh...m/~easycom/<!-- m -->)

See the new very unglamorous site.

In an effort to bring more attention to the homepage above, I've linked to it from a couple of old COM/OLE topics. At some point, I'll also add some links to it from the AHK docs (e.g. DllCall).

Finally, it might be helpful to put a link on <!-- m -->http://www.autohotke...c21674.html<!-- m --> (i.e. this topic) so that people have a way to contact you and leave feedback.

Thanks for spending all this time to provide this often-requested capability!