[Qt] Can't create sf::RenderWindow using Qt's winId method

[korczurekk]

I haven't been using QT&SFML integration for a few months and today I've realised my previous code stopped working, most likely after updating to SFML 2.4 (from 2.3.2).

#include <SFML/Graphics/RenderWindow.hpp>
#include <QApplication>
#include "mainwindow.h"

int main(int argc, char *argv[])
{
        QApplication a(argc, argv);
        MainWindow w;
        w.show();

        sf::RenderWindow app((sf::WindowHandle) w.winId()); //Code stops here

        return a.exec();
}
 

It just stops, no error message or anything. Can anybody test it on SFML 2.4.0 & Qt 5.7 and some other versions?

Here's code of MainWindow class, most likely not useful at all.

//mainwindow.h

#ifndef MAINWINDOW_H
#define MAINWINDOW_H

#include <QMainWindow>

namespace Ui {
class MainWindow;
}

class MainWindow : public QMainWindow
{
    Q_OBJECT

public:
    explicit MainWindow(QWidget *parent = 0);
    ~MainWindow();

private:
    Ui::MainWindow *ui;
};

#endif // MAINWINDOW_H
 

//mainwindow.cpp

#include "mainwindow.h"
#include "ui_mainwindow.h"

MainWindow::MainWindow(QWidget *parent) :
    QMainWindow(parent),
    ui(new Ui::MainWindow)
{
    ui->setupUi(this);
}

MainWindow::~MainWindow()
{
    delete ui;
}
 

[korczurekk]

Okey, I recently found some time to look into this. The problem does NOT occur on SFML 2.3.2, not at all. I recompiled it and with the exact same Qt version it's ok. Also, it isn't a problem with my library only, any other way to get SFML render to Qt doesn't seem to work. Here's an other topic describing this problem: http://en.sfml-dev.org/forums/index.php?topic=21070.0

As drawing to native widget is an SFML feature (is it?), should I mark it as an issue on github?

//edit:
Here's backtrace:
//edit2:
Recompiled SFML 2.4.0 in debug mode; more precise backtrace.

#0  0x00007ffff5d57780 in recvmsg () at /usr/lib/libc.so.6
#1  0x00007ffff451aba7 in  () at /usr/lib/libxcb.so.1
#2  0x00007ffff451b4d8 in  () at /usr/lib/libxcb.so.1
#3  0x00007ffff52d4b89 in  () at /usr/lib/libX11.so.6
#4  0x00007ffff52d4cfb in  () at /usr/lib/libX11.so.6
#5  0x00007ffff52d4fed in _XEventsQueued () at /usr/lib/libX11.so.6
#6  0x00007ffff52b1bfb in XCheckIfEvent () at /usr/lib/libX11.so.6
#7  0x00007ffff79323d7 in sf::priv::WindowImplX11::processEvents() (this=0xadc020) at /home/kamil/Pulpit/SFML-2.4.0/src/SFML/Window/Unix/WindowImplX11.cpp:603
#8  0x00007ffff79337b2 in sf::priv::WindowImplX11::setVisible(bool) (this=0xadc020, visible=true) at /home/kamil/Pulpit/SFML-2.4.0/src/SFML/Window/Unix/WindowImplX11.cpp:928
#9  0x00007ffff79359b4 in sf::priv::WindowImplX11::initialize() (this=0xadc020) at /home/kamil/Pulpit/SFML-2.4.0/src/SFML/Window/Unix/WindowImplX11.cpp:1607
#10 0x00007ffff7931905 in sf::priv::WindowImplX11::WindowImplX11(unsigned long) (this=0xadc020, handle=37748752) at /home/kamil/Pulpit/SFML-2.4.0/src/SFML/Window/Unix/WindowImplX11.cpp:413
#11 0x00007ffff792a52f in sf::priv::WindowImpl::create(unsigned long) (handle=37748752) at /home/kamil/Pulpit/SFML-2.4.0/src/SFML/Window/WindowImpl.cpp:78
#12 0x00007ffff7929ac2 in sf::Window::create(unsigned long, sf::ContextSettings const&) (this=0x7fffffffe170, handle=37748752, settings=...) at /home/kamil/Pulpit/SFML-2.4.0/src/SFML/Window/Window.cpp:141
#13 0x00007ffff74dfc69 in qsf::QSFMLWidget::showEvent(QShowEvent*) () at /usr/lib/libQSFML.so.1
#14 0x00007ffff6e1cef8 in QWidget::event(QEvent*) () at /usr/lib/libQt5Widgets.so.5
#15 0x00007ffff6dd5e0c in QApplicationPrivate::notify_helper(QObject*, QEvent*) () at /usr/lib/libQt5Widgets.so.5
#16 0x00007ffff6ddd581 in QApplication::notify(QObject*, QEvent*) () at /usr/lib/libQt5Widgets.so.5
#17 0x00007ffff6831de0 in QCoreApplication::notifyInternal2(QObject*, QEvent*) () at /usr/lib/libQt5Core.so.5
#18 0x00007ffff6e19b28 in QWidgetPrivate::show_helper() () at /usr/lib/libQt5Widgets.so.5
#19 0x00007ffff6e1c945 in QWidget::setVisible(bool) () at /usr/lib/libQt5Widgets.so.5
#20 0x0000000000403e1a in main ()
 

//edit3:
Apparently it's all because of sf::Window trying to get events by itself (backtrace #7). It didn't work earlier either, but didn't cause anything like that. However there's no documented way to remove events handling without modifying SFML code. Maybe adding sf::RenderWindow::enableEventProcessing(bool) set to true by default would be good idea? Or some fix in backend, maybe it's all caused by some small mistake in code.

[eXpl0it3r]

In what OS does this happen? Try SFML 2.4.1 it contains a few bugfixes.

[korczurekk]

Okay, SFML 2.4.1 works fine, i didn't realize it's already released. 
Btw problem occured on Linux and, most likely, could be reproduced on any Unix-like OS.