Creating COM objects without a need of DLL's

[ptrex]

@Valik

Thanks for your input.

I am still hoping on a simple and creative solution, without a need of a DLL of anykind.

(Like I thought it would never be possible to implement COM objects in AutoIT without a DLL.)

But than again at the end of the day, it might just not be possible at all

We will have to see, but in case if you can and will adjust AutoItX to fit the need, it would be perfect.

I don' t have to explain you what the benifts would be for AutoIT and everyone involved.

regards

pterex

[sohfeyr]

I am still hoping on a simple and creative solution, without a need of a DLL of anykind.

(Like I thought it would never be possible to implement COM objects in AutoIT without a DLL.)

But than again at the end of the day, it might just not be possible at all

We will have to see, but in case if you can and will adjust AutoItX to fit the need, it would be perfect.

I agree with you in principle, but I think we've strayed from the topic. The ability to create COM objects from AutoIT is a powerful revelation. However, I fail to see what purpose it would serve to create such components in raw AutoItX. You would have more flexabiliy with an AU3 or A3X file.

I think the direction I'd like to see this go is being able to create an object in one script and share that object using COM with another script. Another cool direction would be

This would let you do things like, say, compiling PaulIA's Auto3Lib project in an a3x file, running it as a service, and passing complex arguments to the functions - arguments like DLLStructs, Object references and multidimensional arrays. I imagine there are some people who'd like to do something similar with some of the graphics libraries I've seen floating around the forums. (COM supports arrays brilliantly, or at least the Scripting.Dictionary or Collections.SortedList objects do. DLLStruct and Object Reference support is speculative insofar as being AutoIt-compatible.)

Anyways, I think we should focus more on the possibilities than the limitations for right now. This is too powerful a technique to let lie just because we can't say <script language="AutoIt">

[Uten]

What a great first programming experiment for 2007!

Nice sample @sohfeyr...

I expect it to work when I log in as a power user and not as a regular user. So If others starts asking, you do need privileges to register the component. Yes, because you do normally run as a regular user to prevent all those disasters waiting to happen

Had to change this part to get it working (as an administrator):

;$fn=FileOpen($fn,2)
       If FileExists($fn) Then FileDelete($fn)
       FileWrite($fn, $filedata)
       ;FileClose($fn)
       ShellExecuteWait("regsvr32.exe", '"' & $fn & '"');'" -s')
       run("notepad.exe '" & $fn & "'")

If I ran the code as a user regsvr32 will hang (and consume CPU).

[sohfeyr]

Nice sample @sohfeyr...

I expect it to work when I log in as a power user and not as a regular user. So If others starts asking, you do need privileges to register the component. Yes, because you do normally run as a regular user to prevent all those disasters waiting to happen

Had to change this part to get it working (as an administrator):

;$fn=FileOpen($fn,2)
       If FileExists($fn) Then FileDelete($fn)
       FileWrite($fn, $filedata)
       ;FileClose($fn)
       ShellExecuteWait("regsvr32.exe", '"' & $fn & '"');'" -s')
       run("notepad.exe '" & $fn & "'")

If I ran the code as a user regsvr32 will hang (and consume CPU).

That's good to know. What specific OS were you using? I developed that on Win XP Home SP2, and, yes, the user account is in the Administrator group.

BTW,

I learned later that WSC files don't need to be re-registered after they've been changed because the actual component that gets registered is the script host, to which the wsc file is just a parameter or something. So as long as the file name doesn't change, the time-intensive regsvr32 line is optional.

[ptrex]

@sohfeyr

components in raw AutoItX

I think that valik meant that the AutoItX could facilitate providing the infercace. Not meaning that it would contain the actual UDF's.

You would have more flexabiliy with an AU3

I agree on this one the utmost flexible way would be, that it would provide COM support for scripts in AU3 format.

And technically it could because that's what is done by other languages, like PHP, Perl, etc.

and passing complex arguments to the functions - arguments like DLLStructs, Object references and multidimensional arrays. ....

Too complex as a need in the first phase, ... Would be happy if simple AU3 functions could be exposed as COM Objects.

Anyways, I think we should focus more on the possibilities than the limitations for right now. This is too powerful a technique to let lie just because we can't say &lt;script language="AutoIt">

I am glad you see the power of this technique.

This is what WSC is about :

Windows® Script Components provide you with an easy way to create powerful, reusable COM components in script. You create script components using any scripting language that supports the Microsoft® ActiveX® Scripting interfaces. Script languages that support these interfaces include JScript, Microsoft® Visual Basic® Scripting Edition (VBScript), PERLScript, PScript, and Python.

Script Components:

- Are small and efficient.

- Are easy to create, maintain, and deploy.

- Provide the ability to create COM components.

- Provide access to a broad range of system services.

Using script components, you can create COM components for a variety of tasks, such as performing middle-tier business logic, accessing and manipulating database data, adding transaction processing to applications, and adding interactive effects to a Web page using DHTML Behaviors.

Unfortunately it's still a one way directiion at the moment. Providing scripting facilities for other languages to AU3.

Of cource it would be powerfull to have it also the other way around, benifits would be :

- You can create AU3 custom UDF's and share them in other COM comliant applications

- This is most efficient, while you would not have to create the same UDF's in an other scripting language

- Some powerfull featiure which are lacking in other scripting languages will become available in there.

(Maybe even the GUI functions ?! which are missing in the AutoItX at the moment)

- No need to compile DLL to create a AU3 COM object

- flexible because once you have created the WSC file you can just change the UDF logic, press save and that's it you're done.

- Easy to debiug, open SciTE and debug your UDF logic, then copy it in the WSC file press save, done

- Small footprint no need to disctribute DLL's etc.

- ....

So this concept make a good marriage for AU3.

But I guess you all knew that of cource

regards,

ptrex

Edited January 3, 2007 by ptrex

[Uten]

That's good to know. What specific OS were you using? I developed that on Win XP Home SP2, and, yes, the user account is in the Administrator group.

+w2k-SP4

BTW,

I learned later that WSC files don't need to be re-registered after they've been changed because the actual component that gets registered is the script host, to which the wsc file is just a parameter or something. So as long as the file name doesn't change, the time-intensive regsvr32 line is optional.

Sounds good. Did you verify this (with interface changes in the script)?

I also wonder if we can expect the scripting host to be properly installed on all machines (win9x and up) or if this feature only is available on w2k(SPx) and XP.

[ptrex]

@All

I succeeded in running an AU3 script as a COM object, without the need of any kind of DLL.

More info will follow later after more testing. But the first results look OK.

regards,

ptrex

[ptrex]

@all

I can now announce that "AU2COM text based COM Automation server" has been created

Which are the advantages and test results so far :

- Create you own custom COM objects.

- Reuse your AU3 UDF's in other COM compliant applications

- No need to translate AU3 UDF's to other script languages

- FULL exposure of all AU3 commands and functions :

- supports methode, properties and events

- supports parameter functions and variables (Tested)

- supports standard UDF's with return values (Tested)

- supports AU3 GUI controls (Tested)

- supports DLLcall UDF's (Tested)

- supports UDF's including other COM objects, cascading COM calls (Tested)

- supports multidirectional COM comunication (Tested)

- supports reuse of the custom COM opjects in other COM compliant application (Tested)

- supports write back functionality (Not Tested)

- Easy and on the fly debugging of the custom COM objects, using notepad

- Easy and on the fly extendible custom COM objects, using notepad

- Easy distribution of the COM objects, everything it is text based.

..No need to compile DLL's and distribute.

- No need to have an AutoIT full install, on the destination system.

..Only need to have the "AutoIt3.exe" distributed.

- Windows platform independend (as of Windows 98 and later)

..No need to register an &lt;script language="AutoIT"> namespace on the system, to run it.

- Which makes it more transparant and portable to other systems.

- Ease reuse of NON AU3, scripts as COM objects in AutoIT

..Supporting COM interfaces from JScript, Microsoft® Visual Basic® Scripting Edition (VBScript), PERLScript, PScript, and Python to AU3.

- Easy to generate a TypeLibraty files from the custom COM objects for use in COM compliant apps.

..supporting the MS Intellisence technology

- Small footprint perfect marriage for AutoIT

- ...

I hope to add the Demo_examples today in the first post.

Regards

ptrex

[ptrex]

@all

Examples and comments have been added to the first post.

I hope that you are as much impressed, by the new dimension of AutoIT as I am.

Regards,

ptrex

[Uten]

Have not tested it, but trust your work ptrex, and this is just beyond my wildest dreams. Your a genius just for trying to figure it out

I'm off to step on your broad shoulders (technically speaking)

[ptrex]

@Uten

Thanks a lot for the nice compliments !!

Everyone has his expertise.

And I am sure that you have things to show me, of which I don' t have a clue about.

I must admid that I amazed myself this time

See you around !!

ptrex

[Lakes]

This Stuff is WAY over my head, does it mean you can add/call autoit to/from other languages like VB or Python etc?

Not that I use them, just trying to understand what this is about...

[ptrex]

@Lakes

Yes indead. You are correct.

Or to keep it simple for just Word, Excel, Outlook, Powerpoint, DotNet, ASP (.Net), PHP, Oracle scripts, .....

I am noit sure that there is a limited list around.

Anything that is COM compliant will do.

regards,

ptrex

[ptrex]

@Lakes

Yes indead. You are correct.

Or to keep it simple for just Word, Excel, Outlook, Powerpoint, DotNet, ASP (.Net), PHP, Oracle scripts, .....

I am noit sure that there is a limited list around.

Anything that is COM compliant will do.

regards,

ptrex

[Zedna]

Hey ptrex that's really AMAZING!!

As you did most of testing I think your whole first post could be included in standard AutoIt HelpFile

in section "Tutorials" as tutorial for exposing AU3 to COM.

In this section is in similar way described tutorial for "String Regular Expression".

[ptrex]

@Zedna

Thanks again for the feedback and your suggestion to include it in the Helpfile.

I hope the developers pick this up.

Maybe a sticky might help as well for all the other that will miss it, when this post fades out.

I know that there where a lot a users in the AutoItX forum section that requested to get access to the GUI controls by means of COM.

So a reference there might help as well.

But I will leave this up to the DEVS.

regards,

ptrex

Edited January 4, 2007 by ptrex

[ptrex]

@All

Added the "Swiss Army Knife" tools, which helps you get started faster.

Regards,

ptrex

[Uten]

I have gone through and tested the scripts provided now ptrex, and uhh. I must have missed something. Is there any samples of exposing autoit UDF (or native) functionality to the COM client? All I have found is a launcher to launch a autoit application. But no communication between the com client and the server?

Sample: Say, I would like to have a wrapper around StringRegExp to expose that functionality to a vbs script called Manager.vbs.

So I create a AU3_StringRegExp.WSC file with a StringRegExp function. In the StringRegExp function I call autoit to do the job. How do I get parameters from Manager.vbs and back to Manager.vbs

AU3_StringRegExp.WSC.wsc:

<component>
<registration progid="AU3_StringRegExp.WSC"/>
<public>
<method name="StringRegExp">

</method>
<property name="Text" />
</public>


&lt;script language="VBScript">

Function StringRegExp(test, patern, flag)
Dim WshShell, oExec
Set WshShell = CreateObject("WScript.Shell")
'' ---This does not expose autoit functionality it just launches another application??
Cmd = "AutoIt3.exe /AutoIt3ExecuteLine " & chr(34) &"StringRegExp(" & test & ", " & patern & ", " & flag & ")"& chr(34)

Set oExec = WshShell.Exec(Cmd)

set wshShell = nothing
End Function

</script>
</component>

Manager.vbs

testStringRegExp()

Function testStringRegExp()
    Dim WshShell
    Dim res

    Set objWSC = CreateObject("AU3_StringRegExp.WSC")
    res= objWSC.StringRegExp("My test data", "(\w+)", 3)

    ' ---- Itterate res in some way. Is it an array?
    set objWSC = nothing

End Function

How should I modify the code to achieve this?

Can I pass arrays around at all?

Did I miss something essential?

And as a side note. There are some html formating in the code < that can put people off. Maybe you could put all your samples in a zip file to ease testing?

I to agree with @zedna on the help file thing. I only think all solutions to common tasks (and limitations) have to be covered first. I might do the tutorial if I can get my head around the solutions and limitations.

Best Regards

Uten

[ptrex]

@Uten

Please investigate this Example :

expandcollapse popup

<?xml version="1.0"?>
<component>
<registration
description="MyScriptComponent"
progid="Test.WSC" 
version="1.00" 
classid="{7428c732-9472-422e-9878-bdca8433db0e}"
> 

</registration>

<public>
<property name="MyProp1" internalname="iNum1"/>
<property name="MyProp2" internalname="iNum2"/>
<method name="MyMethod1"> 
<PARAMETER name="iValue1"/>
<PARAMETER name="iValue2"/>
</method>
<method name="MyMethod2">
</method>
</public> 

&lt;script language="VBScript"> 
<![CDATA[ 

dim iNum1
dim iNum2 

sub MyMethod1(iValue1, iValue2)
iNum1=iValue1
iNum2=iValue2
end sub 

function MyMethod2()
MyMethod2 = iNum1 + iNum2
end function

]]> 
</script>

</component>

Save this as "Simple 2 parameter.wsc" + Register

; Initialize COM error handler 
$oMyError = ObjEvent("AutoIt.Error","MyErrFunc")

$objWSC = ObjCreate("Test.WSC")

If IsObj($objWSC) then
$MethodWSC_1 = $objWSC.MyMethod1( 3, 4 )

Consolewrite("The Returned Result is : " & $objWSC.MyMethod2()& @CR)


Else 
    MsgBox(0,"Error","No good Object declared")
EndIf   

Func MyErrFunc()
  $HexNumber=hex($oMyError.number,8)
  Msgbox(0,"COM Test","We intercepted a COM Error !"       & @CRLF  & @CRLF & _
             "err.description is: "    & @TAB & $oMyError.description    & @CRLF & _
             "err.windescription:"     & @TAB & $oMyError.windescription & @CRLF & _
             "err.number is: "         & @TAB & $HexNumber              & @CRLF & _
             "err.lastdllerror is: "   & @TAB & $oMyError.lastdllerror   & @CRLF & _
             "err.scriptline is: "     & @TAB & $oMyError.scriptline     & @CRLF & _
             "err.source is: "         & @TAB & $oMyError.source         & @CRLF & _
             "err.helpfile is: "       & @TAB & $oMyError.helpfile       & @CRLF & _
             "err.helpcontext is: "    & @TAB & $oMyError.helpcontext _
            )
  SetError(1)  ; to check for after this function returns
Endfunc

Than run this AU3 script.

What it does is, it provides 2 data parameters in the "$objWSC.MyMethod1( 3, 4 )" object.

Passes it to the COM Object, that does something with it. In this case calculate the 2 together.

And passes the Result back as output to the Script.

Maybe this simple Demo can help you understand the mechanism, to take it a little further.

But best way to learn is still read more on the MSDN.

Because this is a simple Demo. To get more complex things going you might need to dig a little deeper.

I hope this could help you going.

Regards,

ptrex

OEPS TYPING ERROR CORRECTED

Edited January 4, 2007 by ptrex

[sohfeyr]

I see how you are accessing COM from AU3, but it sounded like you were also able to access AU3 from COM?