Final Concern with EXE before I buy

[macroman]

Hello all,

I do not want to come off dramatic, but I've been losing hair for the past 2 months trying all sort of Macro software, including the big expensive one, Automation something... their image recognition is worst than Jitbit and vtask! anyway, imagine recognition is very important for me, and Macro Scheduler works/matches/recognized my tasks probably 9/10 times! I'm sold thus far... However, other apps works 7/10 and 8/10 times as well... but for some reason, when after compiling to EXE... the darn thing performs so poorly! Can Macro Scheduler guarantee that the EXE will work just like it is now with the demo running the tasks from the software?

[Marcus Tettmar]

Hi,

I hope I can alleviate your concerns. First off, there is *zero* difference between a macro that runs inside Macro Scheduler and a macro that runs inside a .EXE. Both include *exactly* the same script engine. It is *impossible* for there to be any difference in the way the macros run and are interpreted.

That is assuming of course that both your native script and the .exe version are being compared running on the same system and the same environment.

If you have moved the .exe to a different PC to the one you run Macro Scheduler on and you are seeing differences then those differences MUST BE environmental - *they are not* caused by any difference between how a script runs in an .EXE and how it runs natively because *there is no difference* in how the script interpreter works - *it is the same* script engine.

Most likely then the issue is a difference in environment which you need to take account of and you'd get exactly the same outcome if you were to install Macro Scheduler on that new environment and run the script internally.

It could be a different theme, different font setting, different font size, different color depth etc. While image recognition is pretty tolerant (if using CCOEFF) there will always be a limit. Even the latest cameras with facial recognition will get it wrong sometimes and that is way more advanced.

So it is important to try and make sure the environments are as similar as possible and if you can't do that factor in the chance of differences and either recapture the images for the new environment or where possible provide a different set of images to suit. If you have no control over the appearance and things change drastically then image recognition may not be the best approach at all (assuming there is an alternative).

Also don't forget to copy of your BMP_DIR folder and runtime DLL. Or nothing will work at all!

The difference in operation may be something else altogether. Taking image recognition out of the equation, the most common cause of things being less than reliable or working differently on another system is TIMING. Different environments run at different speeds and timing is dynamic. Your script may work fine on your own super fast PC where things happen in a snap and then fail on a slower PC because there are places in your script where you have not considered timing. Either waits are too short, or you need more dynamic waits, or both. I've supported Macro Scheduler now for 17 years, so I know - timing is the number one issue and one that often fails to be considered. Many times when someone has a macro which has been working on their PC for ages and then they move it to a different PC and it fails - it's timing. Either down to bad assumptions and lack of intelligent waiting methods, or lack of waits altogether, or waits that are too short, key send rates that are too fast etc.

So as well as looking carefully at your needle images and any differences in the visuals, think about slowing down your script and/or improving how you wait for things to be ready. You can always slow your .exe right down initially by setting STEP_DELAY at the top. Amazing how often that "fixes" things. You can then work on slowing down only the bits that need slowing down.

Either way, the issue is environmental. Nothing to do with EXE vs Script. The EXE simply contains the script and the SAME script engine that Macro Scheduler contains. There is NO difference between them. So the issue is the different environment and the way the script has been written to cope - or not - with those differences.

Hope this helps.

[newuser]

I'm not into image recognition much but I found a simple method of getting the job done.

1) When running image recognition, may I suggest setting the screem resolution and colour the same as the test pc. It work for me.

2) A 32bit colour setting isnt much different with a 24bit colour setting(thats what I found out, some old graphic cards max colour is 24bit only), but a 16bit colour setting is totally different from 24bit or 32bit colour setting. You have to take it into consideration.

3) Save the target pcs same application screen(the ones that need image recognition) as bitmap(not jpeg) files and use it as the test pc desktop wallpaper, then run the image recognition script/exe on the test pc desktop wallpaper, did it detect the image you want correctly?

By taking in the above rules, so far my little image recognition script work well(I won't say 100% unless someone complaint about it). Just my personal little experience with image recognition. Not much.

[CyberCitizen]

I would also make sure you have your waits set correctly. I have found compiled exe's run quicker than in the editor so if I am compiling something I make sure I have the required waits etc.

I believe that is something to do with the way the editor handles the output / input or something. I remember Marcus mentioning something in a post somewhere & don't have the time to look for it.

That being said all the guys here are very helpful & Marcus is very active on the forums if you run into trouble. If you do buy your not only getting an amazing program, but fantastic support.

I have also been able to successfully use MS to integrate with Tesseract-OCR for that harder to capture data etc.

Well worth the money, you can do amazing things with MS.
http://www.youtube.com/watch_popup?v=XR ... M&vq=hd720

[PaulSR]

Just to add we also assessed Automation Anywhere and there was nothing it was offering that MS couldn't do (and better in some cases) - considering the gulf in price thats' quite something.

Image recognition stuff has been covered here already - I built a macro used across 200 PC's and occasionally we'll see issues where IR fails due to a difference which is visible to the eye onscreen. It is possible to alleviate by setting up multiple IR's to cover a scenario where one fails (i.e if you don't see image A look for image B instead - they'd both be the same button but possibly at different resolutions or colours).

A LOT of the time a problem with a script execution will be down to timing. It can look on execution as if the code is simply not recognising the screen but often I've found it's related to using a WAIT instead of a WAITFORSCREENIMAGE or similar.

As Cybercitizen says you won't struggle for assistance with any scripts you're writing on these forums - it's a wonderfully helpful community.

[macroman]

After a few weeks of going at this; it all comes down to timing... timing is the key when you are trying to do this in multiple computers... even if the computer has the same specs, sometime firefox decides to open up slower than others... sometime the TAB key decides to be slower than normal... would hate to make every action to wait 10-30 seconds...but it does get the job done when I set the wait time longer and longer...

[CyberCitizen]

After a few weeks of going at this; it all comes down to timing... timing is the key when you are trying to do this in multiple computers... even if the computer has the same specs, sometime firefox decides to open up slower than others... sometime the TAB key decides to be slower than normal... would hate to make every action to wait 10-30 seconds...but it does get the job done when I set the wait time longer and longer...

If that is the case, you can then use image rec to wait until a part of the screen is ready / showing that should resolve the manual waiting.

[PaulSR]

I've had problems with timings before (primarily with websites) and this snippet of code that was offered up on the forums here proved to be a Godsend in avoiding using overly long waits to compensate.

Code: Select all

Let>WSI_TIMEOUT=1

Label>WaitingForImage2
  WaitScreenImage>%BMP_DIR%\image_001.bmp,0.7,CCOEFF
  If>WSI_TIMEDOUT=TRUE
    Wait>1
    Goto>WaitingForImage2
  EndIf

[CyberCitizen]

That would never time out though if the image never appeared.

[Marcus Tettmar]

Yes, it's rather odd code. It does precisely the same as this single line:

WaitScreenImage>%BMP_DIR%\image_001.bmp,0.7,CCOEFF

The rest is redundant.

But anyway, I think the lesson here is that timing is the most important thing about automation. Computers are dynamic machines. The time it takes between say a mouse click and a window becoming ready for input is NEVER the same.

Web pages are even worse - the load time is dependent on the network speed which is going to be different every time. You can't just assume it will take half a second to load. So Dynamic waits are important.

We humans are able to detect "readiness" subliminally. We're used to it - we don't usually think about how we do it. Usually it's just a visual cue - something on the screen that tells us we're good to go and start typing or whatever it is we want to do.

When automating we need to figure out what this cue is and tell the script to do the same thing.

Image Recognition is probably the easiest way to do this because it is the closest analogy to how we work as humans - by watching the screen.

But with web pages we have other tricks - IEWaitDocumentComplete knows when IE has done loading the page (but has no idea what the page does AFTER it loads - so some thing further may be needed depending on the page).

Another option with web pages is looking for the existance of an HTML element or piece of text - create a loop which extracts some html or text for example - keep looping until found.

Bottom line - it's all about timing. Scripts run way faster than humans can type. Most apps we want to automate were never designed to be automated and so weren't designed to accept keystrokes faster than a human can send them. So we often need to slow things down, add waits and make waits as intelligent as possible where possible.

Functions like UISetValue may not need waits so much because they aren't simulating keyboard entry - they're working at a lower level - but you still need to make sure the window you are setting values on is actually there yet! No good trying to send values to a window which doesn't exist yet.

http://help.mjtnet.com/article/6-top-ti ... ble-macros

[PaulSR]

That would never time out though if the image never appeared.

It was JRL who came up with it in response to an issue I was having where a website wouldn't load timeously if I used the waitscreenimage command in the manner you should (it appeared to interrupt the page loading).

Details here:

http://www.mjtnet.com/forum/viewtopic.php?f=2&t=8220

I should have been clear it works best in that context not for general applications - apologies.

[Marcus Tettmar]

Ah, I see. Yes, it introduces a longer delay into the wait loop. Now we have the context it makes sense.

[JRL]

@PaulSR

No need to apologize. The script you posted is a good example of precisely what Marcus has been explaining. A script needs to be carefully crafted if it is expected to function properly on disparate computers. Timing is everything. Sometimes there is a seemingly trivial trick like this one that can make all the difference in how your script performs across computers with differing configurations.

Glad the script snippet works for you. It has helped me too.