Re: [Interest] Crash when creating QNetworkAccessManager in qt 5.14.x
Have you tried to comment out cleanup of reply objects (QNetworkReply) ? On Thu, Feb 6, 2020 at 8:49 AM maitai wrote: > > I've checked it already, and anyway a QFileDialog is a QWidget and as such > cannot be created before QApplication (that's what it said when I tried). > > Philippe > > > > > Le 05-02-2020 21:20, Henry Skoglund a écrit : > > Hi, maybe you already checked this, but if you have any big wheels like a > QFileDialog declared static, their ctors most likely will run before main(), > i.e. some COM/networking activity could occur before main() kicks in. > > On 2020-02-05 21:10, maitai wrote: > > As I said, I now have doubts it comes from COM threading... > > I have built a small app with nothing inside, with the same .pro file exactly > (qt modules, libs, etc, in the same order). The only difference is HEADERS > and SOURCES of course, main.cpp being the same at least until it crashes. No > problem in this small app (running in the same directory). > > Again for those who missed it: > > main.cpp: > > QNetworkAccessManager *inet = new QNetworkAccessManager(); > > delete inet; > > QApplication app(argc, argv); > > this works. > >QApplication app(argc, argv); > >QNetworkAccessManager *inet = new QNetworkAccessManager(); > > delete inet; > > this crashes on new in our app, not in a sample without HEADERS and SOURCES. > > I cannot understand that, certainly there is something obvious I am missing. > > Philippe Lelong. > > > ___ > Interest mailing list > Interest@qt-project.org > https://lists.qt-project.org/listinfo/interest > > ___ > Interest mailing list > Interest@qt-project.org > https://lists.qt-project.org/listinfo/interest ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Crash when creating QNetworkAccessManager in qt 5.14.x
I've checked it already, and anyway a QFileDialog is a QWidget and as such cannot be created before QApplication (that's what it said when I tried). Philippe Le 05-02-2020 21:20, Henry Skoglund a écrit : > Hi, maybe you already checked this, but if you have any big wheels like a > QFileDialog declared static, their ctors most likely will run before main(), > i.e. some COM/networking activity could occur before main() kicks in. > > On 2020-02-05 21:10, maitai wrote: > >> As I said, I now have doubts it comes from COM threading... >> >> I have built a small app with nothing inside, with the same .pro file >> exactly (qt modules, libs, etc, in the same order). The only difference is >> HEADERS and SOURCES of course, main.cpp being the same at least until it >> crashes. No problem in this small app (running in the same directory). >> >> Again for those who missed it: >> >> main.cpp: >> >> QNetworkAccessManager *inet = new QNetworkAccessManager(); >> >> delete inet; >> >> QApplication app(argc, argv); >> >> this works. >> >> QApplication app(argc, argv); >> >> QNetworkAccessManager *inet = new QNetworkAccessManager(); >> >> delete inet; >> >> this crashes on new in our app, not in a sample without HEADERS and SOURCES. >> >> I cannot understand that, certainly there is something obvious I am missing. >> >> Philippe Lelong. > > ___ > Interest mailing list > Interest@qt-project.org > https://lists.qt-project.org/listinfo/interest___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Crash when creating QNetworkAccessManager in qt 5.14.x
Hi, maybe you already checked this, but if you have any big wheels like a QFileDialog declared static, their ctors most likely will run before main(), i.e. some COM/networking activity could occur before main() kicks in. On 2020-02-05 21:10, maitai wrote: As I said, I now have doubts it comes from COM threading... I have built a small app with nothing inside, with the same .pro file exactly (qt modules, libs, etc, in the same order). The only difference is HEADERS and SOURCES of course, main.cpp being the same at least until it crashes. No problem in this small app (running in the same directory). Again for those who missed it: main.cpp: QNetworkAccessManager*inet=newQNetworkAccessManager(); deleteinet; QApplicationapp(argc,argv); this works. QApplicationapp(argc,argv); QNetworkAccessManager*inet=newQNetworkAccessManager(); deleteinet; this crashes on new in our app, not in a sample without HEADERS and SOURCES. I cannot understand that, certainly there is something obvious I am missing. Philippe Lelong. ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Crash when creating QNetworkAccessManager in qt 5.14.x
As I said, I now have doubts it comes from COM threading... I have built a small app with nothing inside, with the same .pro file exactly (qt modules, libs, etc, in the same order). The only difference is HEADERS and SOURCES of course, main.cpp being the same at least until it crashes. No problem in this small app (running in the same directory). Again for those who missed it: main.cpp: QNetworkAccessManager *inet = new QNetworkAccessManager(); delete inet; QApplication app(argc, argv); this works. QApplication app(argc, argv); QNetworkAccessManager *inet = new QNetworkAccessManager(); delete inet; this crashes on new in our app, not in a sample without HEADERS and SOURCES. I cannot understand that, certainly there is something obvious I am missing. Philippe Lelong. Le 05-02-2020 17:06, Henry Skoglund a écrit : > On 2020-02-05 16:32, maitai wrote: > >> Hi Rainer, >> >> Unfortunately your suggestion didn't work >> >> I have added in my pro file: >> >> win32: QMAKE_LFLAGS += /CLRTHREADATTRIBUTE:MTA >> >> and I can see the option in the link command (I also tried the 2 other >> possibilities STA and NONE of course), but that does not fix anything. >> >> My feeling is that it does not come from CoInitializeEx() finally, because >> anyway in regular builds we are calling it at the very beginning of main, >> before creating QApplication or QNetworkManager, so the threading model >> should be already determined. > Hi, I've seen similar discussions re. COM threading model and Qt, mostly > though they are about QFileDialog and not QNetworkManager, anyways one > solution seems to be to call CoUninitialize when switching the threading > model, more for example here: > https://stackoverflow.com/questions/46581081/qt-qfiledialog-create-unknown-com-object-and-security > > P.S. Also that linker switch /CLRTHREADATTRIBUTE:MTA isn't that mostly for > .NET programs? > > ___ > Interest mailing list > Interest@qt-project.org > https://lists.qt-project.org/listinfo/interest___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Python staticmethod slot
Related issue: https://bugreports.qt.io/browse/PYSIDE-1217
-Original Message-
From: Interest On Behalf Of Jérôme Godbout
Sent: February 5, 2020 2:56 PM
To: Cristián Maureira-Fredes ;
interest@qt-project.org
Subject: Re: [Interest] Python staticmethod slot
Hi,
The init did not changed anything, here is the minimal replicate. I will open a
bug if I did not made any obvious error there.
Thanks,
Jerome
-Original Message-
From: Interest On Behalf Of Cristián
Maureira-Fredes
Sent: February 5, 2020 11:28 AM
To: interest@qt-project.org
Subject: Re: [Interest] Python staticmethod slot
On 2/5/20 4:29 PM, Jérôme Godbout wrote:
> __
> Python code:
> __
> import math
> from PySide2.QtCore import QObject
> from PySide2.QtGui import QVector3D
>
> class PointHelper(QObject):
> @staticmethod
> @Slot(QVector3D, result=bool)
> def pose_position_is_nan(pose: QVector3D) -> bool:
> """This does not work"""
> return math.isnan(pose.x()) or math.isnan(pose.y())
>
> @Slot(QVector3D, result=bool)
> def pose_position_is_nan2(self, pose: QVector3D) -> bool:
> """This does work"""
> return math.isnan(pose.x()) or math.isnan(pose.y())
>
> ...
> qmlRegisterType(PointHelper, "Toto", 1, 0, 'PointHelper')
>
> __
> Qml
> __
> import Toto 1.0
>
> PointHelper
> {
> id: pointHelper_
> Component.onCompleted:
> {
> pointHelper_.pose_position_is_nan2(Qt.vector3d(0,0,0)) // this
> does work
> pointHelper_.pose_position_is_nan(Qt.vector3d(0,0,0)) // this
> does not work, console log: MyFile.qml:63: TypeError: Property
> 'pose_position_is_nan' of object PointHelper(0x1988c36ba10) is not a function
> PointHelper.pose_position_is_nan(Qt.vector3d(0,0,0)) // this
> does not work, console log: MyFile.qml:64: TypeError: Property
> 'pose_position_is_nan' of object [object Object] is not a function
> }
> }
>
> Maybe I'm missing something?! If you want actual minimal running example I
> can provide it.
>
> Thanks,
> Jerome
Hello,
AFAIK when you use qmlRegisterType, you should have a constructor that call the
inherit constructor, and when using setContextProperty, you are allowed to not
call the constructor.
So I'd say you should add a:
def __init__(self, parent=None):
QObject.__init__(self, parent)
for that case.
I'd check the examples directory,
for some use cases of those two scenarios:
https://code.qt.io/cgit/pyside/pyside-setup.git/tree/examples/declarative
If still following the example mechanism, I'd recommend you open a bug report
with a minimal reproducible example.
Cheers
--
Dr. Cristian Maureira-Fredes
R&D Manager
The Qt Company GmbH
Erich-Thilo-Str. 10
D-12489 Berlin
Geschäftsführer: Mika Pälsi,
Juha Varelius, Mika Harjuaho
Sitz der Gesellschaft: Berlin,
Registergericht: Amtsgericht
Charlottenburg, HRB 144331 B
--
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
Re: [Interest] Python staticmethod slot
Hi,
The init did not changed anything, here is the minimal replicate. I will open a
bug if I did not made any obvious error there.
Thanks,
Jerome
-Original Message-
From: Interest On Behalf Of Cristián
Maureira-Fredes
Sent: February 5, 2020 11:28 AM
To: interest@qt-project.org
Subject: Re: [Interest] Python staticmethod slot
On 2/5/20 4:29 PM, Jérôme Godbout wrote:
> __
> Python code:
> __
> import math
> from PySide2.QtCore import QObject
> from PySide2.QtGui import QVector3D
>
> class PointHelper(QObject):
> @staticmethod
> @Slot(QVector3D, result=bool)
> def pose_position_is_nan(pose: QVector3D) -> bool:
> """This does not work"""
> return math.isnan(pose.x()) or math.isnan(pose.y())
>
> @Slot(QVector3D, result=bool)
> def pose_position_is_nan2(self, pose: QVector3D) -> bool:
> """This does work"""
> return math.isnan(pose.x()) or math.isnan(pose.y())
>
> ...
> qmlRegisterType(PointHelper, "Toto", 1, 0, 'PointHelper')
>
> __
> Qml
> __
> import Toto 1.0
>
> PointHelper
> {
> id: pointHelper_
> Component.onCompleted:
> {
> pointHelper_.pose_position_is_nan2(Qt.vector3d(0,0,0)) // this
> does work
> pointHelper_.pose_position_is_nan(Qt.vector3d(0,0,0)) // this
> does not work, console log: MyFile.qml:63: TypeError: Property
> 'pose_position_is_nan' of object PointHelper(0x1988c36ba10) is not a function
> PointHelper.pose_position_is_nan(Qt.vector3d(0,0,0)) // this
> does not work, console log: MyFile.qml:64: TypeError: Property
> 'pose_position_is_nan' of object [object Object] is not a function
> }
> }
>
> Maybe I'm missing something?! If you want actual minimal running example I
> can provide it.
>
> Thanks,
> Jerome
Hello,
AFAIK when you use qmlRegisterType, you should have a constructor that call the
inherit constructor, and when using setContextProperty, you are allowed to not
call the constructor.
So I'd say you should add a:
def __init__(self, parent=None):
QObject.__init__(self, parent)
for that case.
I'd check the examples directory,
for some use cases of those two scenarios:
https://code.qt.io/cgit/pyside/pyside-setup.git/tree/examples/declarative
If still following the example mechanism, I'd recommend you open a bug report
with a minimal reproducible example.
Cheers
--
Dr. Cristian Maureira-Fredes
R&D Manager
The Qt Company GmbH
Erich-Thilo-Str. 10
D-12489 Berlin
Geschäftsführer: Mika Pälsi,
Juha Varelius, Mika Harjuaho
Sitz der Gesellschaft: Berlin,
Registergericht: Amtsgericht
Charlottenburg, HRB 144331 B
--
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
main.py
Description: main.py
main.qml
Description: main.qml
PySide2==5.14.0
shiboken2==5.14.0
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
Re: [Interest] Python staticmethod slot
On 2/5/20 4:29 PM, Jérôme Godbout wrote:
> __
> Python code:
> __
> import math
> from PySide2.QtCore import QObject
> from PySide2.QtGui import QVector3D
>
> class PointHelper(QObject):
> @staticmethod
> @Slot(QVector3D, result=bool)
> def pose_position_is_nan(pose: QVector3D) -> bool:
> """This does not work"""
> return math.isnan(pose.x()) or math.isnan(pose.y())
>
> @Slot(QVector3D, result=bool)
> def pose_position_is_nan2(self, pose: QVector3D) -> bool:
> """This does work"""
> return math.isnan(pose.x()) or math.isnan(pose.y())
>
> ...
> qmlRegisterType(PointHelper, "Toto", 1, 0, 'PointHelper')
>
> __
> Qml
> __
> import Toto 1.0
>
> PointHelper
> {
> id: pointHelper_
> Component.onCompleted:
> {
> pointHelper_.pose_position_is_nan2(Qt.vector3d(0,0,0)) // this
> does work
> pointHelper_.pose_position_is_nan(Qt.vector3d(0,0,0)) // this
> does not work, console log: MyFile.qml:63: TypeError: Property
> 'pose_position_is_nan' of object PointHelper(0x1988c36ba10) is not a function
> PointHelper.pose_position_is_nan(Qt.vector3d(0,0,0)) // this
> does not work, console log: MyFile.qml:64: TypeError: Property
> 'pose_position_is_nan' of object [object Object] is not a function
> }
> }
>
> Maybe I'm missing something?! If you want actual minimal running example I
> can provide it.
>
> Thanks,
> Jerome
Hello,
AFAIK when you use qmlRegisterType, you should have a constructor
that call the inherit constructor, and when using setContextProperty,
you are allowed to not call the constructor.
So I'd say you should add a:
def __init__(self, parent=None):
QObject.__init__(self, parent)
for that case.
I'd check the examples directory,
for some use cases of those two scenarios:
https://code.qt.io/cgit/pyside/pyside-setup.git/tree/examples/declarative
If still following the example mechanism,
I'd recommend you open a bug report with a minimal
reproducible example.
Cheers
--
Dr. Cristian Maureira-Fredes
R&D Manager
The Qt Company GmbH
Erich-Thilo-Str. 10
D-12489 Berlin
Geschäftsführer: Mika Pälsi,
Juha Varelius, Mika Harjuaho
Sitz der Gesellschaft: Berlin,
Registergericht: Amtsgericht
Charlottenburg, HRB 144331 B
--
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
Re: [Interest] Crash when creating QNetworkAccessManager in qt 5.14.x
On 2020-02-05 16:32, maitai wrote: Hi Rainer, Unfortunately your suggestion didn't work I have added in my pro file: win32:QMAKE_LFLAGS+=/CLRTHREADATTRIBUTE:MTA and I can see the option in the link command (I also tried the 2 other possibilities STA and NONE of course), but that does not fix anything. My feeling is that it does not come fromCoInitializeEx() finally, because anyway in regular builds we are calling it at the very beginning of main, before creating QApplication or QNetworkManager, so the threading model should be already determined. Hi, I've seen similar discussions re. COM threading model and Qt, mostly though they are about QFileDialog and not QNetworkManager, anyways one solution seems to be to call CoUninitialize when switching the threading model, more for example here: https://stackoverflow.com/questions/46581081/qt-qfiledialog-create-unknown-com-object-and-security P.S. Also that linker switch /CLRTHREADATTRIBUTE:MTA isn't that mostly for .NET programs? ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Crash when creating QNetworkAccessManager in qt 5.14.x
Hi Rainer,
Unfortunately your suggestion didn't work
I have added in my pro file:
win32: QMAKE_LFLAGS += /CLRTHREADATTRIBUTE:MTA
and I can see the option in the link command (I also tried the 2 other
possibilities STA and NONE of course), but that does not fix anything.
My feeling is that it does not come from CoInitializeEx() finally,
because anyway in regular builds we are calling it at the very beginning
of main, before creating QApplication or QNetworkManager, so the
threading model should be already determined.
@Mårten
I have never succeeded to get a stack trace or to debug with
Windows/MSVC, sorry (I usually debug stuff under Linux only).
I have tried a build with MINGW64 instead of MSVC in the hope I will be
able to get a trace, but as one can expect... no crash in that case.
Philippe
Le 05-02-2020 11:53, Rainer Wiesenfarth a écrit :
>> [...]
>
>> That being said, even if I remove this call and all references to WMI code
>> and CoInitializeEx (including the links to wbemuuid and ws2_32), it still
>> crashes if i do not create QNetworkManager before QApplication...
>
>> [...]
>
> Our experience is that only the first call to CoInitializeEx() succeeds and
> that subsequent calls with a different threading model fail.
>
> That being said, I _assume_ that *both*, QNetworkManager and QApplication
> reach a call to CoInitializeEx() somewhere deep down the code (e.g. in a
> loaded plugin or even an Explorer extension), and these two calls differ in
> the selected threading model. For your application the two cases are:
>
> QNetworkManager before QApplication: QNetworkManager initializes its desired
> threading model, the call to CoInitializeEx() in QApplication fails, but does
> not cause any harm.
>
> QApplication before QNetworkManager: QApplication initializes its desired
> threading model, the call to CoInitializeEx() in QNetworkManager fails and
> causes a crash.
>
> To avoid the call to QNetworkManager before QApplication, you should probably
> use the /CLRTHREADATTRIBUTE:{MTA,STA,NONE} linker flag (in VS: Linker -
> Advanced - CLR Thread Attribute) with the correct value for your case.
>
> Cheers, Rainer
> --
>
> Software Engineer | Trimble Imaging Division
> Rotebühlstraße 81 | 70178 Stuttgart | Germany
> Office +49 711 22881 0 | Fax +49 711 22881 11
> http://www.trimble.com/imaging/ | http://www.inpho.de/
>
> Trimble Germany GmbH, Am Prime Parc 11, 65479 Raunheim
> Eingetragen beim Amtsgericht Darmstadt unter HRB 83893,
> Geschäftsführer: Rob Reeder, Jürgen Kesper
> ___
> Interest mailing list
> Interest@qt-project.org
> https://lists.qt-project.org/listinfo/interest___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
Re: [Interest] Python staticmethod slot
__
Python code:
__
import math
from PySide2.QtCore import QObject
from PySide2.QtGui import QVector3D
class PointHelper(QObject):
@staticmethod
@Slot(QVector3D, result=bool)
def pose_position_is_nan(pose: QVector3D) -> bool:
"""This does not work"""
return math.isnan(pose.x()) or math.isnan(pose.y())
@Slot(QVector3D, result=bool)
def pose_position_is_nan2(self, pose: QVector3D) -> bool:
"""This does work"""
return math.isnan(pose.x()) or math.isnan(pose.y())
...
qmlRegisterType(PointHelper, "Toto", 1, 0, 'PointHelper')
__
Qml
__
import Toto 1.0
PointHelper
{
id: pointHelper_
Component.onCompleted:
{
pointHelper_.pose_position_is_nan2(Qt.vector3d(0,0,0)) // this
does work
pointHelper_.pose_position_is_nan(Qt.vector3d(0,0,0)) // this does
not work, console log: MyFile.qml:63: TypeError: Property
'pose_position_is_nan' of object PointHelper(0x1988c36ba10) is not a function
PointHelper.pose_position_is_nan(Qt.vector3d(0,0,0)) // this does
not work, console log: MyFile.qml:64: TypeError: Property
'pose_position_is_nan' of object [object Object] is not a function
}
}
Maybe I'm missing something?! If you want actual minimal running example I can
provide it.
Thanks,
Jerome
-Original Message-
From: Interest On Behalf Of Cristián
Maureira-Fredes
Sent: February 5, 2020 9:42 AM
To: interest@qt-project.org
Subject: Re: [Interest] Python staticmethod slot
On 2/4/20 10:16 PM, Jérôme Godbout wrote:
> Hi,
>
> Since the doc is pretty slim, and I have no clue how to make this
> work, anyone known how to call a staticmethod slot into PySide2 from Qml?
>
> This do work:
>
> @Slot(QVector3D, result=bool)
>
> def myfct(self, pos: QVector3D) -> bool:
>
> # ...
>
> return True
>
> But this doesn't work:
>
> @staticmethod
>
> @Slot(QVector3D, result=bool)
>
> def myfct(pos: QVector3D) -> bool:
>
> # ...
>
> return True
What's the error you get?
I would like to know why "doesn't work".
> How does one can call this properly?!? Do I have to make a duplicated
> function wrapper with the self that call the function without self
> just for Slot exposure? Right now the only workaround is to do this ugly mess:
>
> @staticmethod
>
> def myfct(pos: QVector3D) -> bool:
>
> return True
>
> @Slot(QVector3D, result=bool)
>
> def myfct_qml(self, pos: QVector3D) -> bool:
>
> “””Use _qml to change name since I cannot have the same name”””
>
> return MyClass.myfct(pos)
Yes, that doesn't look good.
Trying a small hello world does work though:
class MyWidget(QWidget):
def __init__(self):
QWidget.__init__(self)
self.button = QPushButton("Click me!")
self.layout = QVBoxLayout()
self.layout.addWidget(self.button)
self.setLayout(self.layout)
# Connecting the signal
self.button.clicked.connect(self.magic)
@staticmethod
@Slot()
def magic(self):
print("hello")
> I really hate to have to do this and having to create an Object
> Instance on top of it to call the function. Make it hard to have some
> Static Helper function (Q_INVOKABLE equivalent of C++) expose to Qml engine.
> This add up to the lack of qmlRegisterSingletonType. This is getting
> pretty ugly for simple function exposure.
Are you trying to get some "self.something" inside the slot?
because that will not work.
Let me know why it doesn't work,
and we can continue the discussion.
Cheers
--
Dr. Cristian Maureira-Fredes
R&D Manager
The Qt Company GmbH
Erich-Thilo-Str. 10
D-12489 Berlin
Geschäftsführer: Mika Pälsi,
Juha Varelius, Mika Harjuaho
Sitz der Gesellschaft: Berlin,
Registergericht: Amtsgericht
Charlottenburg, HRB 144331 B
--
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
Re: [Interest] Python staticmethod slot
On 2/4/20 10:16 PM, Jérôme Godbout wrote:
> Hi,
>
> Since the doc is pretty slim, and I have no clue how to make this work,
> anyone known how to call a staticmethod slot into PySide2 from Qml?
>
> This do work:
>
> @Slot(QVector3D, result=bool)
>
> def myfct(self, pos: QVector3D) -> bool:
>
> # ...
>
> return True
>
> But this doesn't work:
>
> @staticmethod
>
> @Slot(QVector3D, result=bool)
>
> def myfct(pos: QVector3D) -> bool:
>
> # ...
>
> return True
What's the error you get?
I would like to know why "doesn't work".
> How does one can call this properly?!? Do I have to make a duplicated
> function wrapper with the self that call the function without self just
> for Slot exposure? Right now the only workaround is to do this ugly mess:
>
> @staticmethod
>
> def myfct(pos: QVector3D) -> bool:
>
> return True
>
> @Slot(QVector3D, result=bool)
>
> def myfct_qml(self, pos: QVector3D) -> bool:
>
> “””Use _qml to change name since I cannot have the same name”””
>
> return MyClass.myfct(pos)
Yes, that doesn't look good.
Trying a small hello world does work though:
class MyWidget(QWidget):
def __init__(self):
QWidget.__init__(self)
self.button = QPushButton("Click me!")
self.layout = QVBoxLayout()
self.layout.addWidget(self.button)
self.setLayout(self.layout)
# Connecting the signal
self.button.clicked.connect(self.magic)
@staticmethod
@Slot()
def magic(self):
print("hello")
> I really hate to have to do this and having to create an Object Instance
> on top of it to call the function. Make it hard to have some Static
> Helper function (Q_INVOKABLE equivalent of C++) expose to Qml engine.
> This add up to the lack of qmlRegisterSingletonType. This is getting
> pretty ugly for simple function exposure.
Are you trying to get some "self.something" inside the slot?
because that will not work.
Let me know why it doesn't work,
and we can continue the discussion.
Cheers
--
Dr. Cristian Maureira-Fredes
R&D Manager
The Qt Company GmbH
Erich-Thilo-Str. 10
D-12489 Berlin
Geschäftsführer: Mika Pälsi,
Juha Varelius, Mika Harjuaho
Sitz der Gesellschaft: Berlin,
Registergericht: Amtsgericht
Charlottenburg, HRB 144331 B
--
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
Re: [Interest] qmlRegisterType in python
On 2/4/20 4:04 PM, Jérôme Godbout wrote: > Hi, > > I was developing a small Python application for a client and I did hit a > wall with the qmlRegisterType variant methods. Python PySide2 is missing > any qmlRegisterSingletonType and qmlRegisterUncreatableType and the like > (PyQt was exposing those). I did find the related issue: > > https://bugreports.qt.io/browse/PYSIDE-574 > > it say fix in 5.14 but it’s not, status is reported. I’m a bit confused > about the real state of it or it’s the trunk of 5.14 that got the fix? Usually that it's just to point out the version where it should be fix. With 5.14.1 released, that remains 5.14, hopefully being fix in the next released. There are a couple of things one needs to implement in PySide, to be able to get those methods available, that's why it's not straight forward to fix it. > https://codereview.qt-project.org/c/pyside/pyside-setup/+/249369 On the discussion you can see why that's not being merged, which is mainly because it exposed the function but had no effect. > I also found that limitation to be really scary for any serious project > planning to use Qt Python: > > https://bugreports.qt.io/browse/PYSIDE-811 As you maybe read on the comments of the issue, that's something from Qt Quick itself. One of the first steps to get this done is to implement Q_ENUM, and I'm currently working on that but I don't have a ETA :( Cheers -- Dr. Cristian Maureira-Fredes R&D Manager The Qt Company GmbH Erich-Thilo-Str. 10 D-12489 Berlin Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B -- ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Keep screen active on desktop
On Sun, Dec 29, 2019 at 3:41 PM Kevin André wrote: > Does Qt provide some platform-independent way to keep the screen > active? Or do I need to submit an enhancement request? I have created an enhancement request for this: https://bugreports.qt.io/browse/QTBUG-81907 ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] QtSQL Module Maintainer
Hi, Mark Brand is the maintainer. That's why bugs get auto assigned to him. To resolve the situation the first step would be to find a new maintainer for the module. -- Alex From: Interest on behalf of roberts...@interia.pl Sent: Wednesday, 5 February 2020 14:26 To: interest@qt-project.org Subject: [Interest] QtSQL Module Maintainer Hi all, I would like to know who is the current maintainer of the QtSQL module. I am asking because all bugs related to the SQL Support component are assigned to Mark Brand, but this person has not been active on Jira for the last few years. Best regards, Robert ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
[Interest] QtSQL Module Maintainer
Hi all, I would like to know who is the current maintainer of the QtSQL module. I am asking because all bugs related to the SQL Support component are assigned to Mark Brand, but this person has not been active on Jira for the last few years. Best regards, Robert ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Crash when creating QNetworkAccessManager in qt 5.14.x
[...]
>
That being said, even if I remove this call and all references to WMI code
> and CoInitializeEx (including the links to wbemuuid and ws2_32), it still
> crashes if i do not create QNetworkManager before QApplication...
>
[...]
>
Our experience is that only the first call to CoInitializeEx() succeeds and
that subsequent calls with a different threading model fail.
That being said, I _assume_ that *both*, QNetworkManager and QApplication
reach a call to CoInitializeEx() somewhere deep down the code (e.g. in a
loaded plugin or even an Explorer extension), and these two calls differ in
the selected threading model. For your application the two cases are:
QNetworkManager before QApplication: QNetworkManager initializes its
desired threading model, the call to CoInitializeEx() in QApplication
fails, but does not cause any harm.
QApplication before QNetworkManager: QApplication initializes its desired
threading model, the call to CoInitializeEx() in QNetworkManager fails and
causes a crash.
To avoid the call to QNetworkManager before QApplication, you should
probably use the /CLRTHREADATTRIBUTE:{MTA,STA,NONE} linker flag (in VS:
Linker - Advanced - CLR Thread Attribute) with the correct value for your
case.
Cheers, Rainer
--
Software Engineer | Trimble Imaging Division
Rotebühlstraße 81 | 70178 Stuttgart | Germany
Office +49 711 22881 0 | Fax +49 711 22881 11
http://www.trimble.com/imaging/ | http://www.inpho.de/
Trimble Germany GmbH, Am Prime Parc 11, 65479 Raunheim
Eingetragen beim Amtsgericht Darmstadt unter HRB 83893,
Geschäftsführer: Rob Reeder, Jürgen Kesper
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
Re: [Interest] Crash when creating QNetworkAccessManager in qt 5.14.x
Any chance we could get a stacktrace from the crash? Or does your build of Qt
not have any symbols?
Mårten
Fra: Interest på vegne av maitai
Sendt: Tuesday, February 4, 2020 7:42:50 PM
Til: Interest@qt-project.org
Emne: Re: [Interest] Crash when creating QNetworkAccessManager in qt 5.14.x
Thanks all for your help
Further findings:
The message concerning COM failing to initialize comes from our app, and is in
fact there always in 5.14.x (regardless of the issue with QNetworkManager)
In the very first lines of main.cpp, we call a static function which for
Windows does
HRESULT hres;
// Initialize COM.
hres = CoInitializeEx(0, COINIT_MULTITHREADED);
if (FAILED(hres))
{
qWarning() << "Failed to initialize COM library. "
<< "Error code = 0x"
<< hex << hres << endl;
return QByteArray();
}
So this part is now broken in 5.14.x. If I put COINIT_APARTMENTTHREADED as a
parameter for CoInitializeEx it seems to work again but I have to check a few
other things before being 100% sure.
That being said, even if I remove this call and all references to WMI code and
CoInitializeEx (including the links to wbemuuid and ws2_32), it still crashes
if i do not create QNetworkManager before QApplication...
Philippe Lelong (a bit confused by all that, I must admit).
Le 04-02-2020 18:17, Rainer Wiesenfarth a écrit :
On Tue, Feb 4, 2020 at 5:18 PM Mårten Nordheim
mailto:marten.nordh...@qt.io>> wrote:
It's likely related to the new network connection monitor inside
QNetworkAccessManager, which uses COM.
Although that by itself shouldn't cause any issues and there's other uses of
COM inside Qt as well. But perhaps you didn't indirectly use it so you didn't
get a conflict earlier.
[...]
This sounds familiar. We ran into a similar issue with QFileDialog crashing due
to the wrong COM threading model being active.
I do not recall the details, but searching for "CLR Thread Attribute" (a
linking parameter) may give you some useful information.
Cheers, Rainer
--
Software Engineer | Trimble Imaging Division
Rotebühlstraße 81 | 70178 Stuttgart | Germany
Office +49 711 22881 0 | Fax +49 711 22881 11
http://www.trimble.com/imaging/ | http://www.inpho.de/
Trimble Germany GmbH, Am Prime Parc 11, 65479 Raunheim
Eingetragen beim Amtsgericht Darmstadt unter HRB 83893,
Geschäftsführer: Rob Reeder, Jürgen Kesper
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
