Qt Webkit bridge ActiveQt string

1.1k Views Asked by At

See also for part of my issue: String passing from JavaScript to Qt/C++ object

I use this custom WebPage on my WebView (using setPage), the strings are passed in wrongly. When I disable calling setPage, the strings passed correctly.

I have a C++ object (that inherits from QWidget) that displays an activeX on a webpage (using ActiveQt and QWebView). The ActiveX object displays just fine. I've registered the custom type and used the Qt MetaType system to instantiate the HTML object.

If I want to update a property of that C++ object (not the ActiveX) and call from JavaScript, the string gets a wrong translation or so. If I pass in some string, I only get a string of 1 character on my C++ method. Viewing the memory tells me that the whole string is present (formattted as UTF-32).

If I now don't call the custom WebPage that loads the plugin for me (using setPage on QWebView), I don't get the ActiveX - which is expected - and the strings are passed correctly.

I don't quite understand why this doesn't work. Even with setPage called, I'm talking to the C++ object via JavaScript/QtWebKit bridge, not to the ActiveX component.

I'm on Windows 7, 64 bit, using Qt 4.7.4.

Some code (C++):

class Device : public QWidget
{
    Q_OBJECT

public:
    explicit Device(QWidget* parent = 0);
    Device(const Device& other);
    Device& operator=(const Device& other);
    ~Device();

    QString name() const;
    void setName(QString);
    Q_PROPERTY(QString name READ name WRITE setName NOTIFY nameChanged)
signals:
    void nameChanged(QString);    
private:
    QAxWidget* ax;
};
Q_DECLARE_METATYPE(Device);

Device::Device(QWidget* parent/* = 0*/)
    : QWidget(parent)
{
    ax = new QAxWidget(this);
    ax->setControl("{...}");
}

QString Device::name() const
{
    return _name;
}

void Device::setName(QString name)
{
    if (_name != name) {
        _name = name;
        emit nameChanged(name);
    }
}

// Needed for ActiveQt objects to work
class MapPage : public QWebPage
{
    Q_OBJECT
protected:
    QObject* createPlugin(const QString& classId, const QUrl& url, const QStringList& paramNames, const QStringList& paramValues);

public:
    MapPage(QObject* parent = 0);
};

// ============================================================================
// Needed for ActiveQt objects to work
MapPage::MapPage(QObject* parent/* = 0*/)
    : QWebPage(parent)
{
    qRegisterMetaType<Device>();
    settings()->setAttribute(QWebSettings::PluginsEnabled, true);
}

QObject* MapPage::createPlugin(const QString& classId, const QUrl& url, const QStringList& paramNames, const QStringList& paramValues)
{
    // Create widget using QUiLoader, which means widgets don't need to be registered with meta object system (only for gui objects!).
    QUiLoader loader;

    QObject* result = 0;//loader.createWidget(classId, view());

    // If loading failed, use the Qt Metatype system; expect objects derived from QObject
    if (!result) {
        //result = static_cast<QWidget*>(QMetaType::construct(QMetaType::type(classId.toLatin1())));
        int id = QMetaType::type("Device");
        void* classPtr = QMetaType::construct(id);
        result = static_cast<QWidget*>(classPtr);
    }

    return result;
}

and then on my window

qRegisterMetaType<Device>();
mapPage = new MapPage(this);
ui.webView->setPage(mapPage);   // Needed for ActiveQt objects to work - makes strings broken
...
ui.webView->setHtml(src);
1

There are 1 best solutions below

1
On

Narrowed it down to an issue probably related to JavaScript/HTML.

//device.name = 'test'; // works 
var str = 'test'; 
previewCameo.view = str; // works 

but when I get the name via a HTML drag-n-drop event (using e.dataTransfer), it fails

var name = e.dataTransfer.getData('name'); 
alert(name); // shows correct name 
device.name = name; // fails <------ 
device.name = e.dataTransfer.getData('name'); // fails <------

So retrieval of the dataTransfer data fails for some reason. Why? On Linux I do get a string back, but its formatted like t[]e[]s[]t[]. Seems like an encoding issue.