OCR Not enough storage is available to process this command

[bbrink]

Hello,

I am automating some reports in an older Visual FoxPro application. I put OCRwindow into a loop to identify when the report data set is done being built and the Export button becomes active. I am not detecting the button, I am detecting text on the application status bar. (the text capture commands and could not read status bar)

OCRWindow works well, but after 12 to 20 loops (seemingly depending on how many other programs are active) I get this error:

Not enough storage is available to process the command.

When the error occurs Windows Task Manager shows msched.exe is using large amounts of RAM. I need to exit the process and restart MS to get things to work again.

It seems the OCR routine is not cleaning up after itself and is causing the issue. Is there some way to force cleanup?

-Bob

p.s. As mentioned above, I had tried the various get text options instead of OCR and they did not work with this application. They did not detect the necessary text. I also tried Image Recognition which worked to detect the Export button becoming active when match = EXACT, but I need to compile this and run on several computers with various operating systems and the Export button looks considerably different on each, I am afraid I would need multiple images and have a maintenance issue. -I have also considered looping through the buttons hotkey, hoping that the until the button becomes active the keys sent will be discarded since they do not fire anything. This works but seems kludgy. Any other ideas to detect the Export button being active?

[Marcus Tettmar]

I'm investigating this to see if I can find a memory leak.

In the mean time- I don't see anything "kludgy" about issuing the buttons hotkey until you have the result you need. Over the years I have used that technique many times. When automating we have to look at all the possible ways we have of knowing when something is ready. A user can see that a button is not enabled and will generally wait until they notice the colour change to tell them it is now ready. But I'd bet many users will hit the keystroke anyway. Doesn't matter as it won't do anything. But once the button is active it will and they get the result they want. Since this is so simple why not make use of this in your macro? It makes total sense to me. So you have a loop that keeps sending the keystroke with maybe a small delay after each iteration, and then it looks to see if it has taken effect (that will often be a new window for example). If that's simple to do then do it. Seems to make more sense than scraping the screen to me.

[bbrink]

Marcus,

Thank you for confirming that sending the keystrokes is acceptable. I liked the sound of that method but in my earlier testing I ran into some issues with it because the dialog I was trying to open also has button with same hotkey as its underlying dialog. Buffered keystrokes were causing problems. I shall slow it down and make sure the loop checks focus.

Thanks again,

Bob

[Marcus Tettmar]

BTW - I found the memory leak in the OCR functions. We'll have a fix available ASAP!

[psiquetp]

I have a very similar issue, any suggestions? Here is my code.

Code: Select all

//Subroutine to wait for some text to appear in a screen area ------------------------------------------
//Input: TEXT_TO_WAIT_FOR     .- Text to try to identify.
//Input: X_CORD,X2_CORD       .- Horizontal coordinates of the searched item
//Input: Y_CORD,Y2_CORD       .- Vertical coordinates of the searched item
SRT>WaitForOCR
  Let>ATTEMPT=0
  While>ATTEMPT<100
        OCRArea>%X_CORD%,%Y_CORD%,%X2_CORD%,%Y2_CORD%,STR_OCR_RESULT
        Trim>%STR_OCR_RESULT%,STR_OCR_RESULT
        IF>STR_OCR_RESULT=TEXT_TO_WAIT_FOR
          Goto>ContinueWaitForOCRNoError
        EndIf
        Let>ATTEMPT={%ATTEMPT%+1}
        Wait>3
  EndWhile
  Let>ERROR_MESSAGE=The value %TEXT_TO_WAIT_FOR% never appeared in the area.
  GoSub>ReportError
  Label>ContinueWaitForOCRNoError
END>WaitForOCR

[Marcus Tettmar]

Which version are you running. An OCR memory leak was fixed in 14.4.02 late last year.

[psiquetp]

14.4.08... one more thing Marcus... everything I did ... dissapeared.
I restarted Windows because I kept getting error dialogs, and puf! gone

I'm sending a support email right now.

[psiquetp]

I was able to find my code in a 005 file... so I continued working...

I'm wondering if this could be a type conversion problem... here is the call I'm doing... might this be related to the way I'm assigning the TEXT_TO_WAIT_FOR variable?

//Wait for the progress bar to reach 100%
Let>X_CORD={%X_CORD%-420}
Let>X2_CORD={%X_CORD%-336}
Let>TEXT_TO_WAIT_FOR=100%
GoSub>WaitForOCR

[psiquetp]

It seems the problem is related to the input parameters... sending X2<X1 was breaking the function.

I guess some kind of validation is needed in the OCRArea function.

[Marcus Tettmar]

Ah, yes that makes sense. We'll add some validation.