Possible Bug with OnEvent when using Arrays

[dgilfillan]

Hi, I think I may have discovered a bug when using the OnEvent with Arrays. Consider below simple Array:


Let>Output="Nothing Yet"
Let>k=0
Repeat>k
Let>k=k+1
ConCat>Output,%CRLF%%k%
Until>k=200
Message>Output


Run this and you will find it only takes a second or so (possibly less!)

Now consider the same simple Array use with OnEvent commands in the same script:


OnEvent>WINDOW_OPEN,Notepad*,2,DoNotepad
OnEvent>WINDOW_OPEN,Word*,2,DoWord
OnEvent>WINDOW_OPEN,Excel*,2,DoExcel

Let>Output="Nothing Yet"
Let>k=0
Repeat>k
Let>k=k+1
ConCat>Output,%CRLF%%k%
Until>k=200
Message>Output

SRT>DoNotepad
Let>NotepadOpen=1
END>DoNotepad

SRT>DoWord
Let>WordOpen=1
END>DoWord

SRT>DoExcel
Let>ExcelOpen=1
END>DoExcel

Run this code and you will find that the message now takes 20+ seconds to appear!!!

Any ideas why this might be happening? Am I missing something?

Thx for any help... Dave.

[dgilfillan]

Hi all, I notice this thread has had a few hits but no replies. I could desperately do with some advice on this as I am developing a script which uses both arrays and event handlers...! Please someone offer some advice... or is this a bug in the program?

If you can't offer any advice then please run the code snippets yourself and confirm if you also experience delays.

FYI - I am using the latest production release of Macro Scheduler (ie v8.0)

Thx

[Marcus Tettmar]

Adding event handlers will slow code execution down since each event handler has to be processed while the script is running. No event handlers means less to process. The more event handlers you have the more the effect will be.

[pgriffin]

I would think you would know when to expect any of the windows you list in your example. I would suggest not using so many event handlers and instead, use GetActiveWindow with a conditional loop based on the app window found.

GetActiveWindow>WindowTitle,x,y
if>WindowTitle=Notepad
do something....
endif>
if>WindowTitle=Word
do something...
endif>

etc.....

There is always another way to get the result you want if the first method you try doesn't suit your application.

[dgilfillan]

Hi, thanks for taking the time to look at the problem.

First to mtettmar...

Why should adding event handlers slow down code execution?

The point illustrated by the above code is that a serious bug appears to exist in the software. I am using only 3 event handlers... along with the simplest of arrays holding only 200 elements! When the code is run with no event handlers it takes about a second... when it is run with the event handlers it takes about 20 seconds... thats twenty times as slow which is surely not right!

Please confirm you are experiencing the same thing and explain why such a simple bit of code should take so long...

Secondly to SkunkWorks...

I appreciate there are different ways to code an application to get the result you need. The code provided is to illustrate the problem clearly between event handlers and arrays. Though from what mtettmar has said it could be a problem with using event handlers full stop!

I am not specifically waiting for the 3 applications; notepad, word and excel... Rather the above code is similar to part of a larger script that I'm writing. I only created this extract as an example so it is not a question of knowing when these particular windows are open... thx anyway!

Can you confirm the delay is happening when you run my code example? If it is then it is surely a bug. There is no way attaching three event handlers (which I presume simply listen out for when a particular window is open) should slow down the creation of a simple array by twenty times!

Your efforts are appreciated...!

[Marcus Tettmar]

Why should adding event handlers slow down code execution?

Simply because you are asking the script to do more work. An event handler must repetitively and continuously be performed throughout the execution of the script (after the point it has been set up). Essentially between each and every script step each event handler is processed. What's more some event handlers will be more intensive than others. E.g. the window event handlers must enumerate all windows on the system each time they are processed, in order to detect the required window event. So in your case you have three window event handlers which will run for each step in the script and each one will poll each and every window on the system looking for a match to see if the event handler condition is true. If you have a loop of 10 lines which iterates 200 times then you have 2000 lines of code being run and therefore the event handler will be processed at least 2000 times. Three event handlers means 6000 executions of the event handler procedure. In this case then the script is enumerating all windows on the system looking for a match for your window event conditions, 6000 times. If you don't think this should add execution time to your script then you have rather unrealistic expectations.

Please confirm you are experiencing the same thing and explain why such a simple bit of code should take so long...

Yes, as expected I experience a slow down in the script execution time due to the extra processing.

To help you understand it better, the equivalent to your three WINDOW_OPEN event handlers, without using OnEvent, would be to add three IfWindowOpen statements after EVERY line of code in your script. Would you not expect that to slow down the script?

[dgilfillan]

Hi, after reading your explanation... it is now much clearer! I fully understand what you are saying.

I was never expecting event handlers to add NO execution time to my script, rather I was shocked that they would add so much!

Basically you are saying that the design of the event handlers in macro scheduler is such that they are processed after every line of script rather than running as seperate processes...

While I can see a very limited use for them, surely this makes them pretty much redundant for any scripts where you want to listen out for an event and do some reasonably involved coding in the meantime?

It sounds to me that this is by design... and that the design itself is flawed. Most programming languages that allow you to set up event handlers or listeners to operate some section of code when a particular event incurs do not impact so severely on the processing of other code.

Do you consider this design a bug? Do you think the OnEvent method should be redesigned or would you suggest that I look for either look for a work around or consider other software. Your advice is appreciated.

[Bob Hansen]

I can confirm that a delay is happening. But I don't know how signigicant.

I copied the script above, and did the following:
Commented out all OnEvent lines, Ran script. Then removed comments one line at a time and reran the scripts. I created log files and ended up with the following results:

NO OnEvents = 21 seconds
1 OnEvent = 28 seconds
2 OnEvents = 32 seconds
3 OnEvents = 37 seconds

So in my tests, each OnEvent added about 5 seconds to the basic script with no OnEvents lines. Test is certainly not clean, other programs in background, connected to Internet, other tasks running in background, etc.

Note that this test uses the final sample script provided with OnEvent lines commented out. So there are some SRT lines of codes included. Those lines are not included in the first sample script, it is just the k loop.

So, perhaps the delay is not just the OnEvent but also the other processes added to process the unused SRT lines?

==========
Edited after submission.
I guess I was testing while you were discussing. I see your responses and guess these tests for delay are not needed.

[Marcus Tettmar]

I do not see the delay incurred as a bug or design fault - whatever method is used to implement the event handlers (whether sequentially or as additional processes) a delay will be incurred as the processor simply has more work to do. Window events and window functions have a lot of work to do, so there are limits to what can be gained however they are implemented.

If such an event handler is necessary then one must accept that there will be a performance hit. Most macros are designed to alleviate manual work and therefore a 5 second delay is not significant - especially if the macro runs unattended - perhaps at night. What is important is that it saves the need to do the work manually. What matters most - that it works reliably or that it works 10 seconds faster? Event handlers are not necessarily needed throughout the entire script either - and can be started at any point. So there is not necessarily a hit throughout the entire script.

However, as any longstanding customer will tell you, we continually strive to improve the product and if we can improve performance we will. OnEvent is quite a new addition and I am sure over time we will find ways to improve it. I see no way that we can eliminate a performance hit entirely, but there may be ways we can make gains.