Compiled Script Doesn't Work Properly

[RNIB]

Hi, total newbie here. Never written a Macro before in my life, way out of my depth but only need to do very simple things with MS so should be able to do it

Anyway I've just downloaded the trial version of MS and the compiler as I'm trying to write a macro for the charity I work for (hence the username) that will automate a very tedious process we have to do on a daily basis.

Basically we record talking books for blind and visually impaired people which means using a format/standard called DAISY. Part of this process creates an XML file which is read by a proprietary program which displays the content of that book as a series of links. Where MS comes in is that once we have the content of the book on screen in terms of the structure i.e. chapters, parts etc, we then have to add in all the pages. This just involves a series of key presses per page but as books can have 100, 200, 300, 1000 pages in them this means a LOT of key presses.

So this is the Macro I've written:

Code: Select all

Input>NumTimes, Enter Numer of Runs:,10
Let>x=0
Repeat>x
SetFocus>EasePublisher
Press CTRL
Press Page Down
WaitWindowChanged>3
Press CTRL
Send>1
Release CTRL
WaitWindowChanged>3
Press Enter
Wait>0.3
Press CTRL
Press Page Down
WaitWindowChanged>3
Release CTRL
Let>x=x+1
Until>x=NumTimes

Just to explain what this does as it will help to understand the problem.

Line 4 sets the focus to the Program that turns the books into the DAISY format. I had to put this in for the EXE as without it, it would effectively try to run on the Windows desktop.

Lines 5 & 6 is the command to move to the next part of the book where you want to add a page. I had to add this in to the EXE because without it, it didn't seem to know where it was within the list of links.

Line 7 just waits for the screen to refresh as when you move to a new section of the book a waveform display of the audio is displayed and that takes a second or so to do.

Lines 8 - 10 open the window where we enter the page number which automatically increments by itself anyway

Line 11 waits for that window to open

Line 12 hits the enter button which adds the page to the link

Line 13 makes the macro wait. For some reason without this both in the exe or in MS the whole thing just stops. I think it's because the program we use takes a fraction of a second to update itself before you can do anything else. I tried using a WaitWindowChanged command instead but it just sat there and then ran very slowly.

Lines 14 & 15 move to the next link in the XML where the process starts all over again.

Now if I run this within MS it works perfectly no problem at all. However when it's compiled as an .EXE file it seems to jump around and misses every other section of the book. So in other words instead of adding a page under each section it adds a page under every other section which obviously isn't right anyway but also means that the page numbering goes completely out.

Is this normal with the compiler?
Does the trial version of the compiler makes things slower compared to the retail version?
Is there something in my script that could explain these actions?

As we are a registered charity funds are always tight so I want to be sure that I can get this to work as an EXE before we spend the money on the software as this script is the only reason we have for buying it in the first place.

[RNIB]

Aha!

Okay I know what the problem is.....I just don't know how to fix it

The problem is lines 4 - 6

In the version I run under MS I don't have those lines (sorry forgot to mention that) but I have had to add them to the EXE version as otherwise it doesn't run them in the program as the EXE file has focus.

So what I want to do is to get the macro to only run those lines once in other words those lines won't get repeated when the macro loops again. How would I do that?

[Marcus Tettmar]

It may be running faster when it is compiled. THere are no restrictions with the trial version. There should be no difference when running compiled than when running in Macro Scheduler.

You have already found you need to use SetFocus - this is because the act of starting the EXE will shift focus - probably to the desktop or to windows explorer - or whatever you clicked on to start the EXE. I advise - ALWAYS use SetFocus. Before sending any keystrokes TELL the software where to send them. Use SetFocus. Always. Is the window title really just "EasePublisher"?

The issue you are seeing is almost certainly timing. Your script isn't waiting to ensure the target application is ready before firing events at it. At the very least add some wait statements in there. Better - if any events cause windows to open/close then use WaitWindowOpen/Closed.

I see you are using WaitWIndowChanged a lot - but you may have misunderstood what this does- this waits until the active window has changed - in that it waits until the active window is now a different window. This may not be what you want.

At the very least try:

Code: Select all

Input>NumTimes, Enter Numer of Runs:,10
Let>x=0
Repeat>x
  SetFocus>EasePublisher
  Wait>1
  Press CTRL
  Press Page Down

  //This line was missing:
  RELEASE CTRL

  WaitWindowChanged>3
  //Is that really what you want to do?  Add a wait here:
  Wait>1

  Press CTRL
  Send>1
  Release CTRL

  WaitWindowChanged>3
  //Is the window changing to a new window?  
  Wait>1
  Press Enter

  Wait>1
  Press CTRL
  Press Page Down
  Release CTRL

  //do you really want this next line?  
  WaitWindowChanged>3

  Let>x=x+1
Until>x=NumTimes

Without seeing the app you are automating it is hard for me to give you a definitive answer. But I wonder if you really want to be using WaitWindowChanged. If you issue something that causes a window to close/appear I would use WaitWindowOpen/WaitWindowClosed.

Increasing wait times, at least during debug, will help slow things down to a more human-like speed and let you see what the macro is doing. Once it is working reliably you can always lower the wait times and speed things up, or better yet, look for better ways to make the script wait only as long as necessary.

Are the right fields/objects focused when you start the macro? Maybe when you start it inside Macro Scheduler you have been using a hotkey and maybe you start it when the correct field in the target app is already highlighted. Perhaps when you start the EXE you have shifted the focus. Perhaps you need to make the script put the cursor in the right field before that ctrl-page-down will do anything.

There are many, many ways to make the script wait for object changes, colours, graphics, text .. etc etc. Lots of things to do to make macros reliable. But let's keep it simple to start with - increase those wait times - slow it up.

I CAN guarantee that we WILL get your exe working. Feel free to call me in the UK and we'll run through it together.

[RNIB]

Hi Marcus, thanks for the reply.

You asked if the Window title is really just EasePublisher. No, the window title will be the title of the particular book we are working on at that time and will be in the following format:

[Title of Book] - EasePublisher - [Path of project]

When I added the SetFocus command I just opened up the Windows Title Drop down list in the editor to select the correct Window. The program I use was listed twice, once as just EasePublisher and again using the above format. As I need this script to work on all books I selected just the one that wasn't project specific.

Is that okay or is there a better way of doing this?

I've now changed the code to:

Code: Select all

Input>NumTimes, Enter Numer of Runs:,10
Let>x=0
Repeat>x
SetFocus>EasePublisher
Press CTRL
Send>1
Release CTRL
WaitWindowChanged>3
Press Enter
Wait>0.3
Press CTRL
Press Page Down
Release CTRL
Wait>0.3
Let>x=x+1
Until>x=NumTimes

WOW what a difference. Using the 'old' code it would take about 25 seconds to add 10 pages. Now it takes about 5 seconds!

Will be placing our order today with any luck, just need to raise a purchase order.

[Marcus Tettmar]

When I added the SetFocus command I just opened up the Windows Title Drop down list in the editor to select the correct Window. The program I use was listed twice, once as just EasePublisher and again using the above format. As I need this script to work on all books I selected just the one that wasn't project specific.

Is that okay or is there a better way of doing this?

Well, if it works it's fine. I expect there is an overall hidden application window called just EasePublisher. SetFocus to that is doing the trick by the sounds of it.

In future if you do need to focus that particular window you could do:

SetFocus> - EasePublisher -*

Speficying PART of the title, and finishing with the asterisk says find a window that CONTAINS this text. So assuming no other windows match this will find your "[Title of Book] - EasePublisher - [Path of project]" window regardless of what [Title of Book] or [Path of project] happen to be.

[RNIB]

Excellent, will give that a try anyway.

Have come up against one problem though with the EXE.

On my computer it all runs very quickly although not at a constant speed i.e. it might add pages in a fraction of a second for 3 or 4 pages, then pause for a couple of seconds and continue.

However on other computers it seems to run quite a lot slower even though the computers are all spec'd almost identically. That's not the end of the world but a little annoying. The main thing is that on all computers it doesnt always loop the number of times we specify. For example we may tell it to run 37 times but it stops after 6 or 10, 17 pages. The number of times it runs does seem to be pretty random unless we specify I number below 10 i.e. anything below 10 will generally always run the correct number of times but anything over 10 is random.

[Marcus Tettmar]

I fail to see why it would do anything random. Unless an invalid number is being entered into the Input box.

Run the EXE with a log file (either compile it in) or run it with:

exename.exe /LOGFILE=c:\somelog.log

Then look at the log file. I will wager my house that the script is firing every line exactly as it is being told to. I would say it is a pretty fair bet that the problem is that the application is not always ready for the input and so some loops are effective and others are not. The app may not always respond in the same timeframe. It all comes back to what I said earlier - the script needs to be coded to make sure it always waits for the app to be ready and allows time for the app to accept and process the input being sent to it.

[ABIVEN]

@ RNIB

"if I run this within MS it works perfectly "

That's really a chance.

I never succeed without a lot of Wait commands as wait>1

Without them one time it works ; another it fails

[Marcus Tettmar]

Some processes are time sensitive - time is needed between events - trying to send keystrokes to the process before it is ready to receive them will render them useless. So the script must be written with delays AND/OR with more intelligent dynamic waits that pause the script just long enough and detect when the app is ready to continue. There are lots of ways to do this with Macro Scheduler.