Sign in to follow this  
Followers 0
theguy0000

doing to things at once...

9 posts in this topic

is it possible to do two things at once with autoit?

example: i want my script to be running as normal while running a constant loop listening on TCP, but I want it all in one program.


The cake is a lie.www.theguy0000.com is currentlyUP images.theguy0000.com is currentlyUP all other *.theguy0000.com sites are DOWN

Share this post


Link to post
Share on other sites



Multi-Threading is not currently an option in AutoIt. There are 2 choices you can do. 1. Use 2 Scripts and $CmdLine Parameters / EnvSet()/EnvGet() at RunTime or 2. Use AdlibEnable() to call a specific function every so many milliseconds to check it.


[center]Common sense plays a role in the basics of understanding AutoIt... If you're lacking in that, do us all a favor, and step away from the computer.[/center]

Share this post


Link to post
Share on other sites

darn.

thanks anyway.


The cake is a lie.www.theguy0000.com is currentlyUP images.theguy0000.com is currentlyUP all other *.theguy0000.com sites are DOWN

Share this post


Link to post
Share on other sites

There's a little thing called an a3x file that I had never used before until today... turns out that little script is quite handy for running multiple things at once. Although it is not true multi-threading, because it is simply running other scripts installed from the main one, it is about as close as I've found you can get. Not only that, but you don't have to compile each one indivually - the .a3x format is almost exactly the script size (it was at least for the small script I tried it on).

Compile an a3x file and FileInstall it into your main script. Then, you can run it from the directory you choose in the FileInstall using the main compiled script. Big space-saver there.

If the subscript does not have an infinite loop inside, you're fine, because it will simply end and go away when it's done. However, if your subscript has an infinite loop in it (as mine did), you're going to want to call it with a simple Run () command, as opposed to RunWait(), and you will definitely want to get the returned PID from the run. Then when you need to close it, simply ProcessClose the PID of the subscript. The exe will be the same name, so you can't simply stop it in the task manager by hand without a risk of stopping the wrong one.

As for communicating between scripts, I know you can call the subscript with parameters, but as for back-and-forth communication, I don't think it would work very well. It depends on the situation, but it would be rather tough if not impossible to have them freely communicate.

Ok, so this description may not be very elegant or 100% accurate, but I just figured this out today and this is what I noticed.

Have fun with multiple scripts.

Share this post


Link to post
Share on other sites

#6 ·  Posted (edited)

Having two AutoIt scripts communicate is trivial if the child has been launched via Run(). The parent script reads the child's data on the child's stdout stream and writes to it on the child's stdin stream. The child writes to the parent on the child's stdout stream and reads from the parent on the child's stdin stream.

Edit: Fixed typo.

Edited by Valik

Share this post


Link to post
Share on other sites

Well there you go, that's what several years of experience gets you - a much greater knowledge of the language (developer status helps too).

I totally forgot about stdout and stdin for this case. Thanks Valik.

Share this post


Link to post
Share on other sites

Having two AutoIt scripts communicate is trivial if the child has been launched via Run(). The parent script reads the child's data on the child's stdout stream and writes to it on the child's stdin stream. The child writes to the parent on the child's stdout stream and reads from the parent on the child's stdin stream.

Here's a good example of just that.

[u]My UDFs[/u]Coroutine Multithreading UDF LibraryStringRegExp GuideRandom EncryptorArrayToDisplayString"The Brain, expecting disaster, fails to find the obvious solution." -- neogia

Share this post


Link to post
Share on other sites

Here's a good example of just that.

Can you please stop resurrecting these threads. Okay, we get it, you wrote a library to help with this. If it's good, people will find it, if it's not, people won't. You don't need to mention your library in every thread about multi-threading.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0