On 2017-12-20 22:42, Rainer Wiesenfarth wrote:
Hi all,
..
..
..
I took a close look at the m_fileDialog in QWindowsNativeFileDialogBase
for the Windows 10 case that gets stuck:
- at (1), m_fileDialog references a vtable in comdlg32.dll!const
CFileOpenSave
- at (3), m_fileDialog references a vtable in
OneCoreUAPCommonProxyStub.dll!0x...
So it seems to be related to Windows "umbrella" libraries, but I have no
idea how. I looked even deeper into where m_fileDialog is getting
assigned and found the call to CoCreateInstance(), where
CLSID_FileOpenDialog and IID_IFileOpenDialog is passed in both (1) and
(3), but in (1) the comdlg32 object is returned while in (3) it is the
OneCore... object.
My guess so far:
1. The constructor or destructor of QPrinter could lead to the
replacement of the object behind CLSID_FileOpenDialog, but
2. this replacement not done always, but is triggered by the "some
magic" part in my application that is executed before (1)
Any ideas what the "some magic" part could be? Unfortunately my
application is quite complex and can not be stripped down easily...
Hmmm, maybe that "magic" part is some UWP functionality, because
OneCoreUAPCommonProxyStub.dll should only be loaded for UWP apps, but
your app is a normal Windows .exe file.
Anyway, one way to get some more insight, add more QPA logging to your
app by including:
#include "qloggingcategory.h"
and then turn it on with:
QLoggingCategory::setFilterRules("qt.qpa.dialogs=true");
Might help to see where to hangup is.
Rgrds Henry
P.S. Looking at the code, I see one possibility, if that FileOpenDialog
window is not visible, then the close will fail and a hang will occur.
But how can be it not visible...
_______________________________________________
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
