Export On-Screen Data to XML



  • Are there existing add-ons or plugins that will take on-screen data and export it to an XML file on the client computer? Essentially we have a client application developed on the qt framework and are looking for a way to export the data held in the on-screen controls to an XML file. This could be initiated by data change on screen or by some end user event. Thanks and please ask questions!



  • you want a way to export all data of all widgets inside this app to xml?
    then iterate all QObjects (or QWidgets) including they children and write all properties (can be received via the QMetaObject system) to XML.

    I know no way to do this now without doing it on your own.



  • Essentially yes, however, I only need the text or value property of the widget. So essentially the data that the end user would be able to modify. Text in text boxes, values in drop downs, True/False in check boxes, etc.



  • QMetaObject provides a way to retreive that property. This property is called the USER property, and will be marked as such for well behaved widgets. See QMetaObject::userProperty().



  • I guess my question is more along the lines of, are there distributable plugins / add-ons that have this type of functionality already built? I am not looking to develop the solution myself, however, before going the route of consulting with a Qt developer, I wanted to inquire if this is something that is already out there.



  • I don't know of any out there, but I can imagine how you could make such a thing... The only thing I know that comes close, is Froglogic's squid. I don't know how they interact with the running application, but they do manage to interact with it for automatic GUI testing.



  • not afaik.

    have you googled for it?



  • So,

    what is possible is using the property widget (is that part of QtDesigner, QtCreator). There was a QtSolution with that.



  • I do not know of any existing solution but should be fairly simple to implement. You just need to provide operators of the form:

    @QXmlStreamWriter* operator << ( QXmlStreamWriter& writer, QWidget* w );@

    In the implementation you should use QXmlStreamWriter to output the user property and then iterate over its child QWidgets and call the operator on each of those in turn.



  • I understand however, that pmcfrack would like to do this without adapting the original Qt program, or did I misunderstand that? I still think that should be possible (if the app is linked dynamically), but a bit more tricky. Sounds like a nice challange :-)



  • Yes if it is linked dynamically you could provide a modified Qt that has the necessary operators and then calls them at a suitable time (when Ok on the dialog is clicked for e.g.).



  • Or, you create a Qt plugin that provides this service, perhaps in the form of a custom proxy style or something like that. However, a modified Qt lib (altered QApplication, I think would be my first vector of attack) would work just as well or better, I guess.



  • 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 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 :)



  • 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.



  • 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!



  • 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?



  • 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



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



  • 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):

    1. 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)
    2. 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...


  • 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?



  • 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).



  • [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).



  • 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.


Log in to reply
 

Looks like your connection to Qt Forum was lost, please wait while we try to reconnect.