Passing commands or variables between 2 exe's

[Realm]

The Basics of what I'm trying to do is Build a Core.exe, and have optional plugins depending on the client side needs....so lets say there is 4 different plugins, Client 'John Doe' only wants 1,2,and 4.....so I would like Core.exe to start Plugin_One.exe wait for finish, than proceed until it needs to call the next plugin. I have been searching in the help files for a way to do this and maybe I'm looking in the wrong places. Could some one point me to UDF's, commands, or a section in the help file that I may learn to achieve this?

I would need to pass 2-5 variables from core to plugin, than 2-5 variables from plugin back to core, which should be the same variables, but different values for most of them.

Edit: I can even pass the variables through an ini file if that is best, but I would still need to understand how to get Core.exe to know when a given plugin has finished its process before proceeding to the next line of code

Edited June 1, 2010 by Realm

[jchd]

Are you refering to the plugin feature (additional DLL(s) specially made and registered so that you can call functions inside them using AutoIt syntax) or something else?

I assume this isn't your case and that you're after IPC. There are many ways to do it: environment variables, named pipes, TCP / UDF loopback, shared memory, lightweight database, STD streams, files, mapped files, in fact too many to list exhaustively. At least that provides you with search terms!

As for synchronous launch, why not use Run[As]Wait?

[Realm]

I pretty much a noob here, but feel pretty confident and comfortable learning new techniques here now. I'm not familiar with DLL's at all, a friend of mine asked if AutoIt could be used with DLL's, but with my lack of knowledge, I was unable to answer him. As for synchronous launch, I am not sure what you are refering to, but if it means for both the Core and the plugin to launch simultaneously, that is not what I need. I need to Run Core.exe...it will run some code and grabbing some basic variables to store globally, it than will check to see what plugins client has installed, than it will run through each one, one by one. example

Core.exe will pass 3 variables to Plugin_one.exe and run it, Plugin_one will do its process pass variables back to core and tell it is done.

Core.exe will then pass 4 variables to Plugin_two.exe and run it, Plugin_two will do its process pass variables back to core and tell it is done.

so on, on, till core has passed all plugins, then it will restart the process all over again till client has stopped it

Edit: after reading about environment variables, I could probablly work with these or even passing the variables through an ini or text file. but my ultimate question would be how do I tell the core to pause, and how do I get the plugin to tell the core it is done so it can move on?

I'm noobishly, but hopefully correctly, thinking that using an evironment variable as a light switch in example:

Core would Run Plugin1

$waitstatus=0

Do

EnvGet($waitstatus)

Until $waitstatus=1

and when the plugin had finished it would set the variable to 1 with

EnvSet($waitstatus, "1")

does this look right?

Edited June 1, 2010 by Realm

[jchd]

I see. Forget the term plugin here, as it refers to something completely different in AutoIt. Talk about external modules or child processes so that people here don't get confused and talk bizarre to you

If you can, keep it simple and use predefined files to pass information back and forth. If that's just a handful of variables, then .INI format is simple and easy to use.

Use RunWait to launch your modules "synchronously" (that means that your main program will pause execution until termination of the running module).

FYI, if you were to run them "asynchronously", you would use Run(<module>) but the core program and the module would run at the same time, which is _not_ what you want.

And yes, AutoIt can deal with classical DLLs.

[Realm]

Talk about external modules or child processes so that people here don't get confused and talk bizarre to you

Are you trying to call me a 'child process', lol, just kiddin

back to the serious matter at hand, I have the other exe's in a folder named 'Plugins' which is in the scriptfolder. so

RunWait(@ScriptDir & "\Plugins\Plugin_One.exe") ; will pause the Core.exe till it has finished

my current plugins are written like an include(which I recently found is not the way I wanted to do it), such as they are nothing more than functions, in which the first function is called from within the core. some from if statements. So this is not going to work that way anymore correct?

I should prolly move the call statements into the plugins, and use the RunWait as the call from the if statements. This will work right? maybe a couple of examples are in order:

Core checks a varirable called $bstat

If $bstat=1 Then _startPluginOne

This was the old way, so here I move '_startPluginOne' to the beginning of actual plugin/child process and reformat line like this

If $bstat=1 Then RunWait(@ScriptDir & "\Plugins\Plugin_One.exe")

There is only one given function called from my 'plugins/child process', never 2 different functions called from same 'plugin/child process' as I was calling them

sorry if I'm coming off noobish, I just wanna make sure I understand this correctly

[jchd]

my current plugins are written like an include(which I recently found is not the way I wanted to do it), such as they are nothing more than functions, in which the first function is called from within the core. some from if statements. So this is not going to work that way anymore correct?

That's correct: it just wont work. Your modules are separate programs which need to behave by themselves. Think of them as grown up children!

But of course they have to cooperate with the core to read / write exchanged data from / to a common format with a common semantics!

You may want to pass command-line argument(s) to the launched modules, which you can read in the modules using the $CmdLine array (see help file).

The module may Return($err) an error code which you may test (see Run command help file).

Hope this is clear for you. Good luck with your tribe!

Edited June 1, 2010 by jchd

[Realm]

Thanks alot jchd for your help.

I will be going with your suggestion to pass the variables through an ini file, seems to be the easiest, almost error-proof way.

RunWait will prolly be the way to go, have'nt ever tested anything like this before, but seems to be very viable.

Command-Line Argumenting seems above me, but I am most definately eager to look into it.

Thanks again for your help!

[Realm]

I encountered another problem after I compiled the scripts.

One of the variables I was passing is an object '$oIE', which turns out, can't be written to an ini file. What I have here is the Core.exe is basically a embedded web viewer with a few additional functions, it works on my website. the addons(as I'm calling the plugins now) run navigation forms and clicks on my website. but since I can't pass $oIE, as I did when they were in seperate include functions, how can I pass the object to another exe?

[jchd]

An IE object, like any COM object, can't be passed over to anything else. To see that you have to realize that it isn't created by AutoIt like a native variable (integer, string, ...). When you do $myObj = CreateObject(<whatever>) you in fact ask the <whatever> COM class (think of it as a <whatever> factory) to create (the right word is "instantiate") such an object and return a "handle" (kind of unique identifier) so that you can later refer to this object and ask it to do this and that.

The issue is that the object is an opaque thing: neither you nor AutoIt exactly know what it looks like really, how it's made. The only things you know are methods (verbs or commands you can shout to it, like "increment yourself by 1") and properties (facts that an object lets you know about it). The object don't reside in AutoIt variable space: all AutoIt knows is the object's handle. Another AutoIt program can't use a handle it doesn't know.

In short, you just can't pass objects around by storing them on disk in the general case.

One exception are "persistant objects" which you can ask to write themselves to disk in their specific format and later (using another program or over the Internet or after sending the USD storage to a friend), use the same <persistant object> factory to rebuild a "live" object in memory from what was stored to disk. Of course, the class (object code) has to be coded specially to achieve this. IE is nowhere a persistant thing.

You're bound to adopt the same paradigm, even if AutoIt isn't an OO language. Make the addon functions part of the core and make your addons act as remotes (like your TV set), just sending "commands" meaning for instance "run function of addon#3". If you're worried about the fact that a simplistic way of passing the "commands" could by used to circumvent licensing (or sort of), you can still make it more interesting by selecting a non trivial, even complex instruction vital to execution of each addon function. Encrypt that source line separately as a string using a decent encryption and when asked to run addon#X pass this string to the addon module which will send back a key for correct decryption of that string. Then Execute() that string in the core. That makes the active presence of the addon imperative for working correctly, while not giving away your "secret" easily.

Is that still clear like mud?

[Realm]

Ouch, that is like a slap in the face.

I was hoping that when cleint needed other addons, I could just pass them the addon with an installer that would modify an existing file to turn a switch on with the Core.exe, so basically there is no way to run extra IE functinality through a addon environment with AutoIt. hhmmm, this will impose a slight problem with my plans, not one that can't be overcome though.

Thanks again for your time, and a very well, but brief, explanation. I'm assuming you are, or once was, involved in teaching. You have a very clear way of explaining things.

Thanks again!

[jchd]

No I never teached, per se. Don't misread me: I was sketching a non-trivial way do have addon functions present but "decently" disabled. You may choose to implement a much more simple way to do the same, just like you explained above. Pushing the reasonning, you see you end up with dropping the addon modules completely and solely rely on a configuration file to decide which feature is available.

But of course there are more wide open opportunities for users to cheat with the system and have all addons working without having paid for all of them. OTOH you probably understand there is little one can do to seriously stop a malvolent hacker to find its way around any "security measure" you imagine, as long as software is involved.

[Realm]

I understand there really is no way around hackers, but my concern was that there is still about a dozen more addons that I would like to write in the future, and just planning a check for and run would have been easier to code into the Core now, so that I can still release the addons at a later date without having them update entire package anyways. I'm currently looking into DLL's which is what a friend of mine suggested as the best solution to all of my needs.

[SmOke_N]

I only skimmed through this thread, so forgive me if I'm off here...

You can pass a var with EnvSet() from the sending info app and EnvGet() from the receiving app, as long as the receiving app looks for it periodically.

You can pass the handle of the IE object, and use _IEAttach() to attach to that object.

One issue you could/may run into that I have, applications like Microsoft Office running, for some reason kills _IEAtach() hwnd option. Unless Dale has fixed that since we last spoke.

Edit:

Keep in mind that EnvSet()/EnvGet() is a simple IPC method, and certainly not the most reliable. There are others like named pipes, wm_copydata, tcp, that users have posted examples or made UDFs for here on the forum.

Edited June 4, 2010 by SmOke_N

[jchd]

Hi SmOke_N!

Are you sure you can pass IE handles around processes?

I never succeeded myself and at least some others had problems as well as exposed in a not too recent thread I can't seem to find again, where the handle of an attached _IE couldn't be used from a child process.

I had bigger problems --even within a single process-- with FF which I'll never try to use again.

@Realm,

AutoIt can't produce DLLs, only compiled languages can. So forget this path, it won't help you.

If it turns out that you actually can pass IE handles around and use them for what you have to do, that would be OK but I just can't help you there.

I flatly apologize if what I asserted about passing IE handles is just plain wrong.

[KaFu]

Maybe seangriffins ChildProc (Parallel Processing) UDF is of interest for you too...

[JohnOne]

For passing variables and such between processes Ive been using this superb method from Greencan.

If you use this method, your core.exe will create a variable(s) in memory and pass your child process the pointers to it on launching it.

I keep it pretty simple by just having 2 variables, One which will indicate that the child process has new data, and one string which is the data and the parent process can parse.

Ive found it absolutely solid.

Hope it helps you too.

Edited June 4, 2010 by JohnOne

[Realm]

Good thing I checked back in on this topic.

@JohnOne, I'm still a noob and your option looks pretty complicated, but from what I perceived, it does'nt show a way to pass objects, such as IE. or maybe my noobishness is blind to it.

@KaFu, I was looking over the same example just 2 days ago, and don't see anything in his functions that would pass objects, If I'm not understanding it correctly, could you point me to the function in which I could pass an Object to another process?

@SmOke_N, I would love to see an example, or at least reference me to some examples or UDF's that could assist in passing on object, I have tried many different routes to no avail. And finding a way to pass an object would be great.

Or at least, if not passing an object, is there a way for a child process to detect object like IE in Parent Process(which is a web browser in a GUI) so that it may instruct on text clicks or navigation?

[SmOke_N]

I didn't realize you were dealing with an embedded control even though you said that in your first post.

I had issues getting the objects handle, so I elected to use the title ( making a unique one, and passing that ).

This is just an example of how to create a new object, in your child process, with a bit of cheaply done IPC.

Just run the parent.au3.

You'll see it navigates initially to Google. Then once you launch the "child.au3/exe" it will navigate to this thread.

Typically I would have used handles, _IEPropertyGet($o_ie, "hwnd"), but as I stated, it kept failing.

PassingIEData.zip

[Realm]

SmOke_N, Thanks a lot for literally making an example for me. It is still a bit foreign to me, but I'm prolly going to spend the evening playing with, till I do understand it. I do believe this will be perfect for my needs!

[Realm]

Please forgive me, but I need a bit of clarification, I have added some comments to a part of the parent gui script, and was hoping you could answer them for me, I'm hoping to better understand how this works.

While 1
    Switch GUIGetMsg()
        Case -3 ; where does this message come from?
            IniWrite($s_ini, "ParentCommandToChild", "Exit", 1) ;what does this do beside set ini state, does something wait for ini to change?
            While ProcessExists($i_pid) ;does this loop until the child process finishes?
                Sleep(250)
            WEnd
            IniWrite($s_ini, "ParentCommandToChild", "Exit", 0) ;what does this do beside set ini state, does something wait for ini to change?
            Exit
    EndSwitch
    If Int(IniRead($s_ini, "child", "readystate", 0)) Then ;I understand it checks for integer, but why, and what if it is 0?
        IniWrite($s_ini, "ParentCommandToChild", "NavigateTo","http://www.autoitscript.com/forum/index.php?showtopic=115196")
    EndIf
    If StringInStr(_IEPropertyGet($o_ie, "locationurl"), "autoitscript") Then ;what does this check for?
        IniWrite($s_ini, "ParentCommandToChild", "Exit", 1)
    EndIf
WEnd

Thanks in advance