Forum Discussion

sarchule's avatar
sarchule
New Contributor
16 days ago

OCR recognition no longer recognizes newline between keywords

I have a set of TestComplete python scripts which utilize the Intelligent Quality add-on and OCR recognition to test a Windows desktop app. The following code was previously successful:

myobj.BlockByText("Log\nIn", spNone)    (the intent here is to find a button which contains the words "Log" and "In" on two separate lines of the button label). 

After upgrading to the latest version of TestComplete (15.63.22.7 x64), this code fails with a "The text 'LogIn' was not found." However, the Full Text output clearly shows that both "Log" and "In" are seen and each of these words is separated by a newline. Another button with a two line label ("New Password") fails in a similar manner. I've tried adding wildcards (e.g., Log*In, Log?In, etc.) but it still fails. If I look at the Full Text output in an editor, I can see that there is a carriage return and linefeed between the words "Log" and "In". Is it possible that I have to represent this differently (than \n) in the latest version of TC and IQ add-on?

When I say previously successful, neither the product under test nor the scripts have changed -- the only difference I can think of is that I upgraded to a new version of TestComplete. I would appreciate any assistance or perhaps instructions on how to roll back to a prior version of TestComplete and Intelligent Quality add-on.

3 Replies

  • rraghvani's avatar
    rraghvani
    Champion Level 3

    Try either '\n', '\n\r', or '\r'.

    You could also Record Script, to see how TC generates the code.

  • sarchule's avatar
    sarchule
    New Contributor

    I've tried all combinations: \n, \n\r, \r\n, and \r but BlockByText still fails to find the button. When recording, TC seems to use absolute screen coordinates in most cases (i.e., specifies specific X and Y coordinate to click). In one case, recording did generate an OCR CheckText call with "*Log\nIn*" string. However, if I use that same string within BlockByText, TC still fails to find it.