Important: Please read the Qt Code of Conduct -

#import issues "QML module not found" line annotation Javascript errors in Creator 4.9.2 & 4.10 on 5.13.x

  • Configuration: Windows 64bit, Creator 4.10 (previously w/ 4.9.2), with both Qt 5.13.1 and 5.13.0 installed, using Kit: MSVC 2017 64bit.

    Hello All!,

    Since upgrading from 5.13.0 to 5.13.1, I now see in Creator Javascript/QML "line annotation" errors/warnings in my existing QML code. (but code builds and runs as intended, so this is a nuisance, that is bothersome and concerning, but not critical).

    This link says: "the import statement matches the Qt's minor version" and gives an example using:
    #import QtQuick.Controls 2.13. (scroll down) But it appears that 5.13.0 and 5.13.1 imports are not automagically supported by Creator (it's still popping up 5.12 as the suggested latest)

    When using Qt 5.13.0 (w/Creator 4.9.2 and most recently with Creator 4.10) the following is fine, no annotation complaints:
    #import QtQuick 2.13
    #import QtQuick.Controls 2.13
    #import QtQuick.Layouts 1.13

    Now if I switch my Kit over to Qt 5.13.1 I see new annotation warnings/complaints (see the screenshot below):
    #import QtQuick 2.13
    #import QtQuick.Controls 2.13 (has a line annotation warning... about ""QML module not found")
    #import QtQuick.Layouts 1.13 (has a line annotation warning... about ""QML module not found")

    Note: changing from *.13 back down to *.12 doesn't make a difference

    I also wonder why the popup in Creator that lists the available module versions, doesn't present the latest *.13 as a valid module choice. It only shows the older *.12 modules as choices. This goes for both Creator 4.9.2 and 4.10. Is this a "known issue"? I did not find anything in

    The other #import issue I see in both Qt 5.13.0 and 5.13.1 is that when C++ classes are registered like this:
    qmlRegisterType<MyObject>("com.mydomain.myapp", 1, 0, "MyObject");

    Also, show an annotation JavaScript/QML error when using the convenient form:
    #import com.mydomain.myapp 1.0

    It appears that Creator/ QML / JavaScript doesn't know how to resolve this style of #import statement.
    I see a "QML module not found..." annotation message with a suggestion to "Use the QML_IMPORT_PATH variable to add import paths" which I am not sure what to make of since MyObject is in the backend C++ module.

    Thanks for any advice on these #import annotation warnings or how I might resolve my #import com.mydomain.myapp 1.0 so that it doesn't report an annotation warning.

    Finally, one other issue I noticed (and fixed) when updating to 5.13.1 and Creator 4.10 is when one uses two files to splits up "form" and "function" logic between the two. For example when I use two files:

    • PageOne.qml and
    • PageOneForm.ui.qml

    I was using a PageOneForm {} scope inside the PageOne.qml file, and after updating to Qt 5.13.1 one is now required to add additional imports into PageOne.qml, QtQuick.Controls to resolve a new scope annotation error. Previously this was not needed, but this new requirement is probably for a reason and an improvement.


  • Moderators

    Hi @jake-0

    I noticed QtC bugging out in some case, like you describe.

    I don't know what is causes, and sometimes it goes away on its own.
    What you can try to do, and it works most of the time for me as well, is briefly changing to an other kit/platform, and changing back to the original, after all the parsing is done.

  • Thanks for the suggestion @J-Hilk, I tried switching to gcc... and back to msvc.
    Switching the build tools did not change anything (I currently do not have another platform installed, but I can try that later).

    I still see JavaScript/QML QtQuick import annotation errors in 5.13.1 (but not if I switch back to 5.13.0 which is still installed):
    Anyone else out there seeing anything similar when updating to 5.13.1? ?
    (the weird thing is there is no complaint about:
    #import QtQuick 2.13 (it's only the other #import lines that display an error).


Log in to reply