64 bit GetTextInit Problems

[armsys]

Unfortunately, with respect to your recommendation, we did try using image recognition, and while it was functional, it is simply too slow for the purpose of this macro (a macro with the purpose of speeding data entry, so image processing delays are a significant issue). In addition, while image recognition is a possible substitute for text recognition, there is currently no reasonable replacement for GetWindowText (FWIW, GetWindowTextEx doesn't work either).
In other words, in this case, the problem is significant enough to create an impasse. And while I am thrilled with Marcus' product overall, since this particular issue has remained unresolved now for over a year without any update (until I resurfaced it), I would say that it is very appropriate that the user community (especially those of us who have paid a significant license fee for use of this product) takes the time to draw attention to real issues such as this and do everything we can to help ensure that it is resolved appropriately.
On that note, I do want to thank Marcus for responding so quickly when I resurfaced this issue. Please do keep us posted as you continue to remind your library developer, so we don't think you have forgotten about us.

Hi bluefin, Actually, the EXACT mode of image recognition is reasonably fast enough. On the other hanad, recalling from my past experience, GetWindowText, when working, isn't fast as I desire.
Speaking only for myself, the complaints from you and djs as to GetWindowText are fair. Unfortunately, there's nothing Marcus, in so far as coding is concerned, can do. I'm sorry for the impasse.

[Marcus Tettmar]

Just a small update in the mean time - GetTextPos will currently only work on the primary monitor. We can find no problems detecting text* in this instance, but it will fail to find text that is on a secondary monitor.

*text that is detectable (i.e. text that is produced using Windows TextOut functions. Not all text is produced this way. Only trial and error will tell you whether text can be captured using this library).

[byersjt]

Since another thread said that the GetTextPos was reported a year ago as not working for Windows 7 64bit, I installed Windows 7 32bit. GetTextPos is still not able to get any text in a Web browser.

That means that I am limited to using absolute pixel positions, which I have to predetermine prior to running the macro. This would be fine if no one ever changed the content of the Web pages, but of course web pages are a bit dynamic. Or, I can try using image matching, but since part is looking for the presence of a particular street name or person name, creating dynamic text images is problematic.

Consequently, I am left with waiting until GetTextPos is fixed, for which I cannot wait another year, or finding another product.

[armsys]

That means that I am limited to using absolute pixel positions, which I have to predetermine prior to running the macro. This would be fine if no one ever changed the content of the Web pages, but of course web pages are a bit dynamic. Or, I can try using image matching, but since part is looking for the presence of a particular street name or person name, creating dynamic text images is problematic.
Consequently, I am left with waiting until GetTextPos is fixed, for which I cannot wait another year, or finding another product.

Would resetting a web browser to the default zoom help?
For Firefox, I routinely use:
Press CTRL
Send>0
Release CTRL

[byersjt]

I always use the default 100%. I tried GetTextPos with IE 10 and with the current version of Chrome. I did not try FireFox.

Without a working GetTextPos, I will have to use the WebRecorder function IEContainsText to see if the dynamic text is there. Of course, this does not tell me where it is on the page. If there, the text (street name, or Name and Age) can be one of a number of clickable lines. So, to get the text position, in order to click on it, I will have to use a series of GetTextAtPoint or GetTextInRect, incrementing the pixels to allow for the current spacing of the clickable lines. I have verified that at least GetTextAtPoint and GetTextInRect functions work on a Web page. I can then do a LClick at the location the text is found.

Presumably, I can then use an IEWaitDocumentComplete. When the new page has loaded, I will have to assume the data I need will be in the same location every time. It has a Title to give me the actual position, but that would require the non-functioning GetTextPos to work on a Web page, which it does not.

Of course, it is just a matter of time before the text I need will have moved, due to changes on the Web page that inevitably occur, which will break my macro. Or, the first set of clickable lines I mentioned will have their spacing changed, which will also break my macro.

Oh, well. That's life without a functioning GetTextPos.

[Marcus Tettmar]

If you're using IE you could try using GetTagPos and get the position of the tag containing the text. If nothing else it will narrow down the area. In some cases, say it's a short piece of text in a SPAN it might be quite accurate. But if part of a longer stream of text will at least narrow it down. All assuming the containing element is identifiable of course. With IE I would usually use the IE.. functions, not text capture.

In the mean time I have been promised an update soon from the library developers. Before you get excited I do NOT know if it has any improvements regarding GetTextPos. Only that it "will support the latest Chrome and Firefox, and also make lots of other improvement."

Once received we will implement and test and release. I would guestimate this will be towards the end of August.

Again, just to manage expectations - at this stage I have no specific info regarding how this might or might not affect GetTextPos.

[djs]

Marcus

Is IEGetTagPos working correctly now?
I know it was broken (see thread http://www.mjtnet.com/forum/post33912.h ... 95e71a4736)

Nothing in the release notes has mentioned it being fixed and when I've tried it recently, it didn't work correctly for me, though I tried it on some crazy web pages and wasn't sure what to blame at the time.

Dan

[kpassaur]

Has this issue with GetTextInRect been corrected? I was using Vista 32 bit with no issues, on a 64 bit Windows 7 machine the same script fails. Sort of acts really screwy as I am looking to capture all of the text in the active window.

So, I set focus to "Program Manager" first then I get the active window, the position etc. On 7 it does not bring back the Window on top as it did in Vista or XP. Thinking that was the issue I put text in Notepad for a test, then I set the focus to Notepad and I tried the capture and nothing was returned. So, it is not just a browser thing. Any idea on a correction time?