QDrag / QDropEvent combase error : Class not registered

[SGaist]

Hi,

Might be unrelated to Qt.

See this bug report for example.

[rtavakko]

@SGaist

Thanks! I looked at a few different threads and thought maybe this is related to Windows 32-bit vs 64-bit DLLs.

I compiled a 32-bit version and the problem remained. I tried Release builds for both 32-bit and 64-bit and the problem went away. Maybe the MSVC debugger is not finding some DLLs or has incorrect settings?

If you have any tips on troubleshooting further I would definitely appreciate it!

Cheers!

[SGaist]

Do you have the same issue if you start one of the Qt drag and drop examples ?

[rtavakko]

@SGaist Yes, I see the same issue with the examples in MSVC debug builds, but release works without errors

[SGaist]

Would it be possible to test a more recent version of Visual Studio ?

[rtavakko]

@SGaist Later than MSVC 2017 or a Qt Creator version later than 4.5.0?

[SGaist]

MSVC or rather the compiler. Qt Creator shall have nothing to do with that issue.

You could also check with the MinGW build to see if you have a similar issue. It might be less intrusive than adding another VS installation to your machine.

[rtavakko]

@SGaist Good point, I'll try the MINGW build first and post the results. Thanks for your help!

[tiho_d]

I experience the same error. I am not sure when it started, but the "Class not registered" error comes up during drag-and-drop move operation. As a result the QListView::paintEvent also does not get called. Interestingly when I move out and in the widget still dragging the object the paintEvent function is called.

I am using Qt 5.15.3 LTS with the latest fully updated VS2019 Enterprise. This happens when using both x86 and x64 bit builds. I did a full rebuild of my project with all libraries, but the error during drag-and-drop still appears in the debug console window.

Some threads suggest that I am using mixed x86/x64 DLLs, but checking all DLLs and binaries report themselves as x86 binaries(respectively x64 in the x64 bit build). (https://stackoverflow.com/questions/1496214/how-to-solve-com-exception-class-not-registered-exception-from-hresult-0x80040)

If you have any idea how to detect which module or COM object is causing this error might help. I have not found a way to trace and fix this.

Any help is very welcome! Thanks!

[rtavakko]

Update on this, I tried a MinGW build (5.12.0 64-bit) with similar results. And to correct something I mentioned earlier, this happens both with debug and release builds.

An important note is that this happens when a drag event is in progress but it is not catageorized as one of the following:

• dragMoveEvent
• dragEnterEvent
• dragLeaveEvent
• dropEvent

So if you drag an item and stop on the receiving widget and stop moving the mouse, you will get this error. Maybe the underlying library in Windows is registering a drag event that doesn't involve movement? A 'dragStopEvent'?

[Zoin]

Any progress on this, anyone? I'm facing the same issue, and it makes my DnD very sluggish. I'm calling it from QML, but it seems it doesn't matter much. All the "smooth QML animations" are essentially screwed up

[Vladimir Orlov]

The same problem. Qt 5.15.2, Qt Creator 5.0.1, VS2019 16.11.3, x86 app on x64 Windows. An interesting thing is that it reproduces in Win10 but in Win8.1 all works well.

I've read somewhere that running an app with Administrator rights could help but didn't try it yet.

For now I have no idea what COM object is not found. Something that controls Drag&Drop on the OS level for dragging items between applications I think.

Upd: the problem must be somewhere in the following module
https://code.woboq.org/qt5/qtbase/src/plugins/platforms/windows/qwindowsdrag.cpp.html

[rtavakko]

@Vladimir-Orlov Running as admin didn't work for me. I have a feeling somehow the drag & drop flag is being set to DROPEFFECT_NONE in the module

[jazzco2]

When I google for "onecore\com\combase\dcomrem\resolver.cxx(2299)\combase.dll" I get a link to a forum of juce.com describing the same issue. As far as I saw it doesn't seem to be based on Qt. Thus I guess the error happens inside of the Windows libraries itself.

[rtavakko]

@jazzco2 Right, but what's the solution? If an older windows dll fixes things, I could try finding and swapping it

P.S. that thread talks about a different issue. It is a crash not a warning with strange behaviour and there is no solution there either