Search the Community

An application is there which is created using vc++,mostly mfc. DOn't know the details completely. WHen I try to automate the control clicks for testing the UI. THe below control is not detected. As you can see, during UI operations I can click the elements one by one. But all the elements is selected as a whole set, when I use the Windowinfo tool. How to click this using AutoIT.? Please suggest.

Hi, I've seen a couple of threads on the topic of interacting with custom MFC controls. So far, I haven't seen any successful methods described, so I thought we could maybe improve on that here? The reason I've started looking at this is that I've been teaching a course involving assembly language for a simulated CPU. I wanted to use AutoIt to construct a simplistic test program to help students evaluate their programs (and so I could mark assignments quicker and more accurately!), but sadly the emulator is built with some kind of MFC custom controls inside MDI child windows, which return nothing via ControlGetText(). The controls appear to be of class AfxFrameOrView42s, which I suppose is some base class they extend. I'm going to investigate (with some dread) MFC more. Until then, I have a couple of basic questions: Are there other Windows messages that MFC controls might respond to with their text?If the control uses some kind of drawing canvas, is it possible to retrieve the canvas handle and the text objects which have been rendered to it?Other techniques... a proprietary tool called ScreenScraper successfully retrieved the window contents, albeit only the text visible at the scroll location onscreen. However, it was fast and accurate, which suggests that it wasn't using OCR. I'd like to be able to distribute simple test scripts without relying on that proprietary library, though.[edit]Other possibilities maybe worth exploring are DLL calls into the MFC libraries to access the MFC document/view objects, or maybe some COM object for same? [edit 2] While I'm at it, it looks like I might be able to hook the GDI drawing calls, and catch the strings drawn to the target window's DC (a bare list of machine registers and contents)... but that seems slightly... awful. But if it's the only way...