Export On-Screen Data to XML

andre

[quote author="ZapB" date="1300010321"]Agreed. Taking it one step further, you could provide a modified QApplication that listens on a tcp socket and serialises all visible widgets (or some subset) upon receiving a suitable network request...or any other input along these lines.[/quote]

My thoughts exactly :)

pmcfrack

The reason that I am looking for a way to export data from widgets to XML, is that we are no longer able to get a text from widgets using WM_GETTEXT. Keep in mind this is a 3rd party application that we have no control over. So, this thread was started as more of a method of working around the issue. Hope that helps clarify the issue.

giesbert

Do you have control over the executable? If not, it get' really interesting...

You could use MSAA to access the data, if the third party app enabled MSAA. This was something that was already proposed to you in your "other thread":http://developer.qt.nokia.com/forums/viewthread/1967/

There is no way to just call get text on a widget where you are not part of the process and have not object pointers!

pmcfrack

We don't have control over the executable. Do you know of a simple way to determine whether or not MSAA is enable, short of writing an app to try it?

giesbert

Have you read my answers on the other thread?

[quote author="Gerolf" date="1290874030"]You have no chance to get the text out of third party. Only if it supoports MSAA (Microsoft Active Accessibility). That's what I told you some posts up. But as you suggested to use Pointer(Of QWidget) = QWidget.find(DirectCast(hwnd..., I said that those classes are only for C++.
But from outside of the process, it's getting difficult. For "normal" Win32 windows classes there are possibilities, but QWidgets do not depend on "normal" Win32 window types.

So, again: try out using MSAA (search "http://msdn.microsoft.com":http://msdn.microsoft.com for it).

For examples on how to program that, you can also look at: "http://www.codeproject.com/KB/winsdk/MSAA_UI_Automation.aspx":http://www.codeproject.com/KB/winsdk/MSAA_UI_Automation.aspx[/quote]

You can use google for tools to check MSAA and also tools to read values via MSAA. Microsoft supports them, e.g. search for: AccExplorer32.exe

andre

I still think the adapted Qt version or plugin aproach is feasable.

giesbert

If you have no control over the app code, you can't adopt it (or use an adopted Qt). That's exactly the point. We saom similar discussion with our system test, as they need some similar features.

There are tqo ways (from my point of view):

Use Squish, but then you need to create some extra stuff that needs to be build while building your application (or you needed it in earlier versions, I don't know the newest ones)
Use MSAA, but to use it, the MSAA pluginb needs to be used from the application. Not sure if it is automatically used when it is placed in the correct plugin folder...

andre

I am confused Gerolf. Why exactly would not be able to use an adapted Qt, or a Qt plugin if you have no control over the app code? As long as the code is dynamically linked, you should be able to replace the Qt libraries with your own, rigged version, right? Or am I overlooking something?

ZapB

I don't think so. As long as the new modified Qt library is binary compatible it should work fine. One subtletty to watch out for would be the plugin build key (if the app uses plugins).

giesbert

[quote author="Andre" date="1300431206"]I am confused Gerolf. Why exactly would not be able to use an adapted Qt, or a Qt plugin if you have no control over the app code? As long as the code is dynamically linked, you should be able to replace the Qt libraries with your own, rigged version, right? Or am I overlooking something?[/quote]

If the Qt version was build by configure without default parameters, how do you know which ones to use? And If you have no access to the code, where to know which internals might be used (although they shouldn't)?

A plug-in must always be used by the code to be instantiated, so if the app code does not load the plug-in, it will not be loaded, right?

Adopted version of Qt would work if you know exactly, which compilers, configure switches etc were used for the app, and if it's not a must for the test to use the same version as it will be used at customer side (one requirement we have, no modified things for tests).

andre

Well... It remains to be seen if the Qt version in use is non-standard, of course. That would be quite easy to try, I think. A standard Qt program takes command line parameters to select things like the QStyle plugin to use. Other plugins are actually loaded on startup, like the SQL drivers. I think you could abuse that. Of course, you might run into trouble, it is not guaranteed to work for each and every situation, but for a relatively standard Qt-based program, I think it would go a long way with a pretty decent change of success.