QuickControls embedded in a Dll



  • Hi everibody,

    I have a very strange behaivor :
    I build a dll to be linked against a 32 bits application made in C.
    For the moment, this dll is very simple. It has a unique shared function which is called by a dedicated thread in the application.. This function creates a QGuiApplication and a QQuickView which loads a simple qml file with a rectangle and a mouse area that controls the rectangle color through a binding.
    So far so good, everything works fine. : the quick view is displayed and I can control the color of my rectangle.

    But as soon as I add to my qml file
    import QtQuick.Controls 1.1
    the quick view is still displayed but with a wrong size and nothing displayed in it (as if there was a syntax error in my qml). Note : only the import statement is enough to create the problem.

    But if, instead of building a dll, I build an app (TEMPLATE=app + use of a function main) using the same qml file, everything works fine, which seems to prouve that my qml file does not have any error.

    I am stucked here. Would you have any idea ?

    Thanks in advance for your help



  • stranger :
    When I start the main app from the Qt debugger my dll works fine, when I start it from visual studio (where it is built), the dll does not display anything.

    At the beginning, I thought it might have something to see with the fact that "the QApplication was not created in the main() thread" (a warning that I have). I am not sure anymore as in both cases (started from Qt or from VS), the QGUIApplication is started in a dedicated thread initiated by the application so not in the main thread.

    What do you think ?


  • Qt Champions 2016

    Fix that warning, pronto! Then see if the problem persists.



  • ok, it's fixed but my problem is still present.
    Actually, I think it might be related to a context, a path or something like that as it works fine when I run it from Qt environmen (run or debug).
    I continue to search.

    For information and if that can help somebody, the warning was due to the fact that I was instantiating a QObject before creating the QGuiApplication.


  • Qt Champions 2016

    @JoBill said in QuickControls embedded in a Dll:

    Actually, I think it might be related to a context, a path or something like that as it works fine when I run it from Qt environmen (run or debug).
    I continue to search.

    This is certainly possible. Have you tried comparing the environments from both IDEs?



  • Nop, but to be honnest, I don't know what to compare or what to check ...


  • Moderators

    @JoBill said in QuickControls embedded in a Dll:

    Nop, but to be honnest, I don't know what to compare or what to check ...

    Check the paths. I'm guessing that when Visual Studio loads your DLL, it doesn't add the import path for Qt Quick Controls to the list, so the module can't be found and imported.

    One way to check is to add qDebug() << QQmlEngine::importPathList() to a function in your DLL, and check your debug outputs when it is loaded from both environments. You can see your debug outputs in either the console (if your app uses it), or using DebugView.

    See http://doc.qt.io/qt-5/qtquick-debugging.html#debugging-module-imports for more debugging techniques.



  • Both are the same.
    But looking more closely to my app output when running from VS (which I should ave done earlier), I found that :

    qrc:/dashboard.qml:2:1: plugin cannot be loaded for module "QtQuick.Controls": Cannot load library C:/Qt/5.5/msvc2013/qml/QtQuick/Controls/qtquickcontrolsplugind.dll: Le module sp?cifi? est introuvable.
    

    Of course, the dll was present in the given path so it is certainly one of its depencies which is missing.
    When looking at it with dependency walker, I got the following warnings :

    Error: At least one required implicit or forwarded dependency was not found.
    Error: At least one module has an unresolved import due to a missing export function in an implicitly dependent module.
    Error: Modules with different CPU types were found.
    
    

    Does that ring something for one of you ?

    Thanks again fro all your help


  • Moderators

    @JoBill said in QuickControls embedded in a Dll:

    Error: Modules with different CPU types were found.

    This means your application has loaded a mix ture of 32-bit and 64-bit DLLs. You must make sure that they are all the same bit-ness.

    Dependency Walker also shows you the path and bit-ness of each loaded DLL; have a closer look.



  • This app is a very old one built with visual studio 6 (please don't laugh too loud :-)). And for the moment, it's too complicate to change that.
    Thus, it is built only for 32 bits target and that is why I force my dll to be built in 32 bits as well. Note : I build the dll with QtCreator using the kit named Desktop Qt 5.5.1 MSVC2013 32bit
    Even if the dll is compiled with a VS 2013 32 bits and not with VS6, I don't see why that would be a problem : a 32 bits app vs a 32 bits dll.

    So I really don't see why this mix exists. And even more, this mix does not exist when I start it from Qt (or at least, the Qt environnement knows how to find its way), so I would rather look on Qt side for the bit-ness mixture (or may be on VS 2013 side) rather than on my app itself.
    What do you think ?

    Now, concerning the Depency Walker, the 6 missing dll's are very deep in the tree
    API-MS-WIN-CORE-WINRT-ERROR-L1-1-0.DLL
    API-MS-WIN-CORE-WINRT-L1-1-0.DLL
    API-MS-WIN-CORE-WINRT-ROBUFFER-L1-1-0.DLL
    API-MS-WIN-CORE-WINRT-STRING-L1-1-0.DLL
    DCOMP.DLL
    IESHIMS.DLL

    and all the other dlls (that are found) are 64 bits (x64) except the specific QT dll (QT5CORED.DLL ....) which are all 32 bits (x86)

    The strange thing is that the root dll (QTQUICKCONTROLSPLUGIND.DLL) comes from c:\qt\5.5\msvc2013\qml\qtquick\controls\ and not from C:\Qt\5.5\msvc2013_64\qml\QtQuick\Controls
    Thus, it should only load 32bits dll no ?

    If that has any sens ....


  • Moderators

    First things first: Do you have Qt in your PATH? If so, remove it now and never put it back in the PATH.

    @JoBill said in QuickControls embedded in a Dll:

    This app is a very old one built with visual studio 6 (please don't laugh too loud :-)). And for the moment, it's too complicate to change that.

    Not a problem at all; I think it's awesome that Qt can work with such a wide range of technologies old and new :-D

    Thus, it should only load 32bits dll no ?

    When you launch an application, the system searches for a DLL based on its name only. The system will load the first DLL that it finds. It doesn't know whether a DLL is 32-bit or 64-bit.

    Now, concerning the Depency Walker, the 6 missing dll's are very deep in the tree
    API-MS-WIN-CORE-WINRT-ERROR-L1-1-0.DLL
    API-MS-WIN-CORE-WINRT-L1-1-0.DLL
    API-MS-WIN-CORE-WINRT-ROBUFFER-L1-1-0.DLL
    API-MS-WIN-CORE-WINRT-STRING-L1-1-0.DLL
    DCOMP.DLL
    IESHIMS.DLL

    These are false positives, and you can ignore them. If you run Dependency Walker on, say, Microsoft Word, it will complain about these DLLs too.

    and all the other dlls (that are found) are 64 bits (x64) except the specific QT dll (QT5CORED.DLL ....) which are all 32 bits (x86)

    I guess you've found the cause of the "Modules with different CPU types were found" error message. The next question is: Why did the system load 64-bit DLLs?

    I can't tell where the issue is, so you'll need to do some detective work.

    Try this:

    1. Launch your application + DLL from Qt Creator
    2. While your app is running, launch Process Explorer
    3. In Process Explorer, select View -> Lower Pane View -> DLLs
    4. Click on your app in the upper pane
    5. Check the list of DLLs in the lower pane
    6. Launch your application + DLL from Visual Studio and repeat the steps above


  • Dear all, I played with the path and I don't know exactly what I did but now, it is working ok.

    thanks all for your help

    Antoine


Log in to reply
 

Looks like your connection to Qt Forum was lost, please wait while we try to reconnect.