[Interest] Windows 10 + native QFileDialog + QPrinter + some magic = application hangs

[Henry Skoglund]

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