Call a Function in compiled EXE or in AU3 script from outside

[ptrex]

Hy guys,

I am working on getting some UDF's translating to COM objects :

AU3 to COM using WSC

Everything is working realy great. But the only thing I need to accomplish is calling a single funtion from outside a compiled EXE or a AU3 script.

I have been testing the C:\Progra~1\AutoIt3\AutoIt3.exe /AutoIt3ExecuteScript and /AutoIt3ExecuteLine,

in combination with the functions CALL() and EXECUTE().

But no success.

Can this be achieved and if so how. Or is there an other way of doing this.

This is the only thing that keeps me from making everything complete and ready to roll.

Thanks

regards,

ptrex

[jpm]

Hy guys,

I am working on getting some UDF's translating to COM objects :

AU3 to COM using WSC

Everything is working realy great. But the only thing I need to accomplish is calling a single funtion from outside a compiled EXE or a AU3 script.

I have been testing the C:\Progra~1\AutoIt3\AutoIt3.exe /AutoIt3ExecuteScript and /AutoIt3ExecuteLine,

in combination with the functions CALL() and EXECUTE().

But no success.

Can this be achieved and if so how. Or is there an other way of doing this.

This is the only thing that keeps me from making everything complete and ready to roll.

Thanks

regards,

ptrex

I am not sure to understand what's you get wrong.

Post example of waht you try to do.

Using those /Autoit3... will not insure you get back a variable return by the function, you just get the return value from AutoIt3.exe

[ptrex]

@Jpm

If you follow the instruction here Test script

You will see what I mean.

I am converting a UDF function to a COM object. This COM object passed Variable values to a AU3 script. This AU3 script then returns the values to the COM object as callback values.

Everything works as expected, the only drawback is that I can only trigger a AU3 script as a whole, which means that it runs all the Functions included in the AU3 or EXE (if compiled).

I need to find a way to trigger only 1 Function in the AU3 or EXE, instead of running everything.

Thanks

[jpm]

If the number of function to be called is well defined and their parameter you can use Call and inside the function a big swith according to the functions to be call. EXECUTE will not work as Com are forbidden as stated in the doc to avoid easy malware script development.

if you go with and spwan AutoiT3.exe you need a client/server communication to send parameter and get back the returns values.

I am not sure that's answer your question. That's all I have in mind for now

[ptrex]

@Jpm

when I run this "C:\Progra~1\AutoIt3\Finance.exe /AutoIt3ExecuteLine "Call("_PV", 1000,3,24)"

To call a function in an compiled EXE with parameters, nothing happens.

Can you give me an example on how to ?

Thanks

ptrex

[Valik]

You can't do anything of the sort. What JP said is you need to write the script like normal except the only thing the script does when you run it is take it's command line parameters and Call() a function. For a simple example:

Main()

Func Main()
    If $CmdLine[0] Then
        Call($CmdLine[1])
    EndIf
EndFunc

Func Test1()
    MsgBox(0, "", "You called Test1()")
EndFunc

Func Test2()
    MsgBox(0, "", "You called Test2()")
EndFunc

Compile that script and then invoke it as "Script.exe Test1" or "Script.exe Test2".

The embedded script is not looked at when you use /AutoIt3ExecuteScript or /AutoIt3ExecuteLine. It makes no sense to look at the embedded script, either, since the idea of both of those features is to provide the runtime engine with a new script to use in place of the embedded script.

[ptrex]

@Valik

Thanks for clarifying.

It' s a pitty, because there is lot's of potential going down the drain this way !!

So I have to be more creative now to find an alternative solution, for the COM objects to call AU3 Functions.

One way to do it probably is to sent along with the COM properties and extra property as an identifier for which function to call.

It's all messy this way but that's the only way I can see it happening for the time being.

Any other creative thougts are welcome.

regards,

ptrex

[jpm]

@Jpm

when I run this "C:\Progra~1\AutoIt3\Finance.exe /AutoIt3ExecuteLine "Call("_PV", 1000,3,24)"

To call a function in an compiled EXE with parameters, nothing happens.

Can you give me an example on how to ?

Thanks

ptrex

That could not work as the function _PV cannot part of the scriptline. Remember you are trying to execute a single script line.

[Valik]

ptrex, you wouldn't want the embedded script accessible when using /AutoIt3ExecuteScript. JP already covered why it doesn't work with /AutoIt3ExecuteLine. Now imagine if the embedded script was accessible when using /AutoIt3ExecuteScript, you'd almost always get "function already defined" errors because the embedded script would have library functions and so would the script you're trying to run. For any non-trivial script, these would clash and the script wouldn't work.

The functionality you're looking for would be better suited as an extension to the a3x format. It would be pretty neat if a3x files were like AutoIt-DLLs in that they have an export table and AutoIt can call exported functions. Then what you want would be possible. However, there are currently no plans to do this.

[ptrex]

@Valik/Jpm

Thanks both for the feedback !!

I will let you all know the workaround after I tested it.

Keep watching the COM without the DLL thread.

See you all around.

Regards

ptrex

[sohfeyr]

The functionality you're looking for would be better suited as an extension to the a3x format. It would be pretty neat if a3x files were like AutoIt-DLLs in that they have an export table and AutoIt can call exported functions. Then what you want would be possible. However, there are currently no plans to do this.

Valik, could you please describe the obstacles involved? It's a design consideration that puzzles me anew every time I do something in AutoIt, and I'd love to hear your take on it from a technical perspective.

Being nowhere near your level of expertise, I can't pretend to be able to do anything with the information except learn - but I like to think that's a noble enough goal? At the same time, I realize this may come close to some of your "top-secret" code (like how you get around restricted memory, the compiler of course, and possibly even the DLLCall secrets) so if there are security issues involved... well, I'll be disappointed, but I'll understand. Probably the most profound thing I've learned from these forums is how many people are out there wanting to use good ideas for bad purposes.

[Valik]

Obstacles involved with what? Making a3x behave sort of like DLLs?

[sohfeyr]

Obstacles involved with what? Making a3x behave sort of like DLLs?

Short answer: Yes

Long answer: Yes, please

Uninformed alternative track that might have a similar effect, or at least lead to some interesting ideas: Another possibily that occurred to me was a UDF solution similar to what Outshynd and WSCPorts are doing here, except instead of targeting an external process the program would target itself using @AutoItPID or AutoItWinSetTitle() and WinGetHandle(). The code in your EXE could have directives to inject the A3x into the tokenized code portion of that same executable while it is running. (Think "The Blob".)

Of course, I probably just demonstrated an enormous lack of comprehension about what exactly it is they are doing, how DLLs work, how compiled AU3 scripts are represented in memory, what exactly the AutoIt compiler does, the relationship between the AutoIt.lib and the rest of the file...

[Valik]

There aren't really any difficult obstacles. It's just a matter of doing it. It's not trivial work, it would take some time to implement, but as far as I can see, there aren't any technical obstacles. It should be no more work than creating a well-described file format to hold an export table and the AutoIt script. The compiler would need modified some to create the export table and the run-time engine would need to know how to parse the exports to find the functions. But it's all just a matter of somebody doing it as opposed to any real obstacle.

[sohfeyr]

There aren't really any difficult obstacles. It's just a matter of doing it. It's not trivial work, it would take some time to implement, but as far as I can see, there aren't any technical obstacles. It should be no more work than creating a well-described file format to hold an export table and the AutoIt script. The compiler would need modified some to create the export table and the run-time engine would need to know how to parse the exports to find the functions. But it's all just a matter of somebody doing it as opposed to any real obstacle.

Thanks, it's nice to know what is involved... even without obstacles, I wouldn't expect it to be "trivial" work. I also appreciate that you don't like to make changes to the code except as bug fixes, and the compiler and runtime engine sound like dangerous places to operate - stuff breaks, after all.

Is there any chance of that other idea working, or being modified in some way to work - sort of an in-memory variation of #include?

[Valik]

It's not really practical. There's no safe way to handle symbol clashes which would be very likely with such a method. It would be an easier scenario to handle in an export-style situation.

[sohfeyr]

It's not really practical. There's no safe way to handle symbol clashes which would be very likely with such a method. It would be an easier scenario to handle in an export-style situation.

That's certainly true. Guess we have to wait for a developer to get interested enough and find time to do it, after all.

I do have another idea for how to expose the functionality of one script to another so that it acts like a library. Do you know of a way to have two scripts interacting with the same COM object at the same time? I've been pondering using ptrex's method of setting up a Windows Scripting Component and GUISetState() with a hidden window. The various functions in that library could get invoked using ObjEvent... except I can't figure out how to share a reference to such an object from another script to fire said events. What is the nature of the value returned by ObjCreate(), and is there any possible way to do what I'm talking about with the current build of AutoIt?

(Yes I know this isn't the help forum, but as long as we're talking implementation maybe one or the other of us can come up with a way that is pragmatically similar to what has been previously discussed here. If you think it's too far off-topic I'll happily repost elsewhere.)

[Valik]

That has nothing to do with AutoIt. Whether or not two references resolve to the same COM object is an implementation detail of the COM object itself.

[sohfeyr]

That has nothing to do with AutoIt. Whether or not two references resolve to the same COM object is an implementation detail of the COM object itself.

Thanks! now I know on which side of the implementation to focus the research. It may not be as clean as having exported functions, but being able to wrap a script in a COM object could be very powerful, and for many purposes just as good.

Edited January 22, 2007 by sohfeyr

[ptrex]

@sohfeyr

Glad to see that you didn't give up yet !!

I do have another idea for how to expose the functionality of one script to another so that it acts like a library

If you got something going, keep us up to date.

My method is stuck using the wrapper function as shown is my post 55 of Creating COM objects without a need of DLL's

Which works, the COM object sends that data between the 2 scripts.

It might not look practicle, but at the end it does what it needs to do.

Regards

ptrex