External Control of AutoIt

11 posts in this topic

MartinMarris 0

I have written an elaborate plugin for a Windows app, using a language called ManuScript, but at one point it will need to "bail out" to an AutoIt! routine that will scrape some info off the screen using the AutoIt! pixel reader facility.

What is the best way for the Windows app to "launch" the AutoIt! routine? It is something that will happen several thousand times in the period of a minute or so. The other app's plugin language does not have the ability to write to the clipboard, so I am thinking, it will have to signal AutoIt! (and swap data back and forth) by writing disk files.

So one way to do this would be to code AutoIt! so that it loops constantly, checking for the disk file, and launching if it finds it. The disk file would be deleted when AutoIt! had completed its screen-reading task and AutoIT! would return to a waiting loop.

Is that the way to go? One disadvantage is that it would require the AutoIt! "loop and wait" routine to be started separately, every time this plugin is to be run. Is there no way for an AutoIt! program to be told, upon booting up Windows, that it should wait indefinitely in the background for a launch command, in the same way that a typical "macro/quickeys" program works? Perhaps it is as simple as putting the AutoIt! program in the "Startup" area?

Thanks! (I'm new to AutoIt! so please expect lots of elementary questions.)

Share this post

Link to post

Share on other sites

MartinMarris 0

No one has made any suggestions, but anyway here's how I proceeded in the end. I created a While/WEnd loop that is launched automatically upon booting Windows. It is only a few lines of code: it waits for a specific named file to be created by the other app, which is the signal to launch an AutoIt! routine (which is a separate file from the While/WEnd loop). This is working well, although I am still wondering whether there is another way to do this.

Hi,

I have written an elaborate plugin for a Windows app, using a language called ManuScript, but at one point it will need to "bail out" to an AutoIt! routine that will scrape some info off the screen using the AutoIt! pixel reader facility.

What is the best way for the Windows app to "launch" the AutoIt! routine? It is something that will happen several thousand times in the period of a minute or so. The other app's plugin language does not have the ability to write to the clipboard, so I am thinking, it will have to signal AutoIt! (and swap data back and forth) by writing disk files.

So one way to do this would be to code AutoIt! so that it loops constantly, checking for the disk file, and launching if it finds it. The disk file would be deleted when AutoIt! had completed its screen-reading task and AutoIT! would return to a waiting loop.

Is that the way to go? One disadvantage is that it would require the AutoIt! "loop and wait" routine to be started separately, every time this plugin is to be run. Is there no way for an AutoIt! program to be told, upon booting up Windows, that it should wait indefinitely in the background for a launch command, in the same way that a typical "macro/quickeys" program works? Perhaps it is as simple as putting the AutoIt! program in the "Startup" area?

Thanks! (I'm new to AutoIt! so please expect lots of elementary questions.)

Share this post

Link to post

Share on other sites

MartinMarris 0

Thanks for the question. No, not directly. It is a self-contained scripting language that is not designed to interface in any way with other applications. It has no access to the system clipboard and cannot directly pipe data to other apps. The workaround that I am using, as you know, is that it can write a text file to a "watched folder" and this becomes the launch signal for AutoIt!

Share this post

Link to post

Share on other sites

SadBunny 125

TOTALLY OFF TOPIC, sorry, but still I would really like to ask a totally non-autoit-related question.

I googled the ManuScript language. I never heard of Sibelius... Programmable musical notation software, that sounds really interesting! Gotta look into that one... There's been an idea lingering in the crevices of my imagination about music generation for years (I am an amateur experimental techno musician) and this could be fun to experiment with. It seems to be something with a high learning curve though, so I am wondering if you could tell me whether or not this could be worth my while. What I would like to accomplish in short is to scriptmatically create layered midi files and/or musical scores, with a lot of knowledge about music theory and with programming skills but without having to learn how to actually write MIDI files. Can I do algorithms for creating musical scores, save that into this Sibelius thing and then use the Sibelius interface to save a MIDI file? (The MIDI files would subsequently be used in Reason or Fruityloops or something.)

Just a question from another music lover

Roses are FF0000, violets are 0000FF... All my base are belong to you.

Share this post

Link to post

Share on other sites

MartinMarris 0

There are currently two dominant music notation programs: Sibelius and Finale. We are professional users of both programs. Both programs come with their own plugin/scripting languages although they are completely different. ManuScript (the Sibelius plugin language) is a fully fledged programming language with a whole lot of power. It does not offer direct access to the Sibelius UI, but instead, enables direct programming to manipulate Sibelius musical scores. Finale comes with FinaleScript, which does offer direct access to the UI but has far more limited programming powers.

We have extended ManuScript's powers by combining it with external scripting programs. We started with ScriptIt, then MacroExpress, and now AutoIt! (the latter, largely because I already have quite a lot of VisualBasic programming experience therefore AutoIt! seemed like a good fit). The challenge in this case is that the creators of ManuScript did not intend for their language to be used in conjunction with others -- so what we are doing is cobbled together rather ad-hoc.

The key concept here, as I have discovered, is that at any one time only one program should be "in charge" of the show. This goes against the grain of modern multitasking, but is necessary in this case. So what I do is have each program terminate and hand over full control to the other, swapping control back and forth (often several thousand times per minute). This is working very well now. I created a "watched folder" and when files appear in that folder it is a signal for AutoIt! to do something, and then terminate and hand control back to ManuScript.

I cannot directly answer your question about musical scores and MIDI. We use MIDI only for playback purposes and our focus is on the visual appearance of a score. Good luck!

TOTALLY OFF TOPIC, sorry, but still I would really like to ask a totally non-autoit-related question.

I googled the ManuScript language. I never heard of Sibelius... Programmable musical notation software, that sounds really interesting! Gotta look into that one... There's been an idea lingering in the crevices of my imagination about music generation for years (I am an amateur experimental techno musician) and this could be fun to experiment with. It seems to be something with a high learning curve though, so I am wondering if you could tell me whether or not this could be worth my while. What I would like to accomplish in short is to scriptmatically create layered midi files and/or musical scores, with a lot of knowledge about music theory and with programming skills but without having to learn how to actually write MIDI files. Can I do algorithms for creating musical scores, save that into this Sibelius thing and then use the Sibelius interface to save a MIDI file? (The MIDI files would subsequently be used in Reason or Fruityloops or something.)

Just a question from another music lover

Share this post

Link to post

Share on other sites

SadBunny 125

There are currently two dominant music notation programs: Sibelius and Finale. We are professional users of both programs. Both programs come with their own plugin/scripting languages although they are completely different. ManuScript (the Sibelius plugin language) is a fully fledged programming language with a whole lot of power. It does not offer direct access to the Sibelius UI, but instead, enables direct programming to manipulate Sibelius musical scores. Finale comes with FinaleScript, which does offer direct access to the UI but has far more limited programming powers.

We have extended ManuScript's powers by combining it with external scripting programs. We started with ScriptIt, then MacroExpress, and now AutoIt! (the latter, largely because I already have quite a lot of VisualBasic programming experience therefore AutoIt! seemed like a good fit). The challenge in this case is that the creators of ManuScript did not intend for their language to be used in conjunction with others -- so what we are doing is cobbled together rather ad-hoc.

The key concept here, as I have discovered, is that at any one time only one program should be "in charge" of the show. This goes against the grain of modern multitasking, but is necessary in this case. So what I do is have each program terminate and hand over full control to the other, swapping control back and forth (often several thousand times per minute). This is working very well now. I created a "watched folder" and when files appear in that folder it is a signal for AutoIt! to do something, and then terminate and hand control back to ManuScript.

I cannot directly answer your question about musical scores and MIDI. We use MIDI only for playback purposes and our focus is on the visual appearance of a score. Good luck!

Thanks for your explanation! There seems to be a demo version of Sibelius available... Hopefully I can use this ManuScript in the demo version, I am very curious what I can do with it! If it is useful for me, I'd be just in time for Christmas!

Roses are FF0000, violets are 0000FF... All my base are belong to you.

Share this post

Link to post

Share on other sites

Theorem 0

No one has made any suggestions, but anyway here's how I proceeded in the end. I created a While/WEnd loop that is launched automatically upon booting Windows. It is only a few lines of code: it waits for a specific named file to be created by the other app, which is the signal to launch an AutoIt! routine (which is a separate file from the While/WEnd loop). This is working well, although I am still wondering whether there is another way to do this.

So the "control_file" is a file that has been created by another app, signaling AutoIt! to open and read the "control_file." That file contains the name of an AutoIt! EXE routine to run (that way, a single While/WEnd loop can serve to trigger any AutoIt! app).

You may initially be puzzled by the two smaller While/WEnd loops inside the code. That's because the biggest issue turned out to be the latency between file commands being issued by AutoIt!, and the actual appearance/disappearance of the real file on the disk drive.

The first loop: without putting it in, the parser never seemed to get beyond the first half of the string that I passed to ShellExecute, i.e. it parsed the path but not the FileRead data.

As for the second While/WEnd loop at the end: it turned out that this was necessary because otherwise, the file doesn't have enough time to get deleted before the loop comes around to it again ... and Windows will go into an infernal loop which may be impossible to stop without a hardware reset! My take on this is that, when the "FileDelete" is issued, AutoIt doesn't wait for the command to complete. Hence my weird fix....

It's working well. I still can't help feeling there must be another way, such as some kind of Windows process that would wait for a trigger. When I get deeper into AutoIt! I will see what I can find. I suspect that the While/WEnd loop may be fairly wasteful of CPU cycles and it is certainly very unforgiving when things go wrong.

More experienced AU programmers should feel free to poke holes in my code ... I tend to go for over-redundancy to be on the safe side. For instance I don't know whether the FileClose is truly necessary prior to the FileDelete.... and I am sure there are much more efficient ways to do process control.