QML and Qt Quick

@Pl45m4 - thanks for the info. By the time I've bought new electronica, it'll likely be available.

@Pl45m4 Sorry about my mistake... It won't happen again.

@GrecKo In my original project, the object with the StringListModel is a singleton. In this new one, the StringListModelExampleClass isn't. Anyway, I had no idea that using macros is now considered "best practice" for communicating with qml, so thank you for the advice! My project is now using the QML_ELEMENT macro, but the console is still logging "undefined." [image: 17ea1e97-17f9-41c1-bef1-21365bf6cfe6.png]

Please read the solution in this post https://forum.qt.io/post/808545

@SeDi said in QML Grid: Grid contains more visible items than rows*columns: It's like parenting: sometimes you just have to trust without setting redundant constraints. That's actually a very good insight - when you use Layouts in QML, you're giving QML permission to handle some things on its own, without as much specific direction from the programmer. They take some getting used to, but they can offer a lot in return.

@maverick997 I don't have any special knowledge about this but there were more comments added to the bug after the 5 March date mentioned in comment #7 of this thread.

Thanks, @SGaist . It turns out that it was sufficient to recreate the engine. I modified the relevant portion of my code as follows: QQmlApplicationEngine *engine; qmlRegisterType<MyClass>("MyClass", 1, 0, "MyClass"); do { engine = new QQmlApplicationEngine; engine->rootContext()->setContextProperty("myClass", &myClass); engine->loadFromModule("restartQml", "Main"); currentExitCode = app.exec(); delete engine; } while (currentExitCode == MyClass::EXIT_CODE_REBOOT); return currentExitCode; } And it seems to work fine. I also discovered that I didn't need to pass in the QGuiApplication to my handler class; evidently this is provided to me via qApp: #include <qguiapplication.h> void MyClass::restartRequested() { qApp->exit( EXIT_CODE_REBOOT ); } Thank you for the help.

The solution without the aliases, or Items, is definitely cleaner and more memory efficient. Unfortunately, Creator can't understand the syntax and provide autocomplete on the properties within the nestings! Using the Item / alias pattern resolves that.

hi thank u for reply @SGaist yes i have checked the file is present and also check the QtLocationPlugin.pri file for SOURCES += $$PWD/QGCMapEngine.cpp is present i just don't know what build flag is missing

@GrecKo Thank you ! Indeed I can use that property :)

This might be a bug or "feature" of this component, then. You can file a report about it on Qt bug tracker.

@SimonLiu Two options: Use an earlier version Build PySide6 yourself

I ran into this issue myself when using QQuickWidget (since you're certainly going to want to be communicating between C++ and Qt Quick in that case). The original comment about setInitialProperties really triggered me, since that means there wasn't parity between QQuickWidget and QQuickView in a way that doesn't make sense. The same was true of the more modern loadFromModule pattern. So I created a couple patches to at least to try and rectify this in 6.9: https://codereview.qt-project.org/c/qt/qtdeclarative/+/586483/2 https://codereview.qt-project.org/c/qt/qtdeclarative/+/586520/1 But also I my case, that doesn't help me "today". I agree that using a QML Singleton is the correct solution over setting a context property, but that still led me to the issue that I wanted to do that the Modern/Correct way, but I didn't really understand from the docs how to get access to that Singleton from the C++ side. I found that this was the correct documentation page that explained that: https://doc.qt.io/qt-6/qtqml-cppintegration-exposecppstate.html But basically this is what the C++ code would look like: Singleton *singleton = engine->singletonInstance<Singleton *>("MyModule", "Singleton"); singleton->setThing(77);

Debugging with RenderDoc, I found that the problem may occur in the "draw" function of the "QRhiCommandBuffer" class. In the original code, I called the "draw" function twice, namely: cb->draw(6, 1, 0, 0); cb->draw(3, 1, 6, 1); I intend to specify the "instanceCount", and the most important parameter - "firstInstance" (the "firstInstance" in the first call is 0, and 1 in the second) for each rendering. Through RenderDoc's debugging (as shown in the figure below), I found that these two calls correspond to two "glDrawArray" function events. The vertex number counts are 6 and 3, respectively, consistent with the numbers in my code, but "glDrawArrays" cannot specify instance ID. [image: 3fdfccc2-f30e-450e-afaf-6b203ac745a3.png] Furthermore, I changed the two "draw" function calls to one but changed the "instanceCount" to 2(draw two rectangle instances), and the firstInstance started from 0: cb->draw(6, 2, 0, 0); This time, the "draw" function corresponds to a "glDrawArraysInstanced" function event in RenderDoc, and the two graphics can use different object matrices. [image: c8968a62-361d-40e6-be47-8ef57cd6b8bb.png] Two rectangle instances with different model matrixes [image: e48dd912-2538-4e31-89eb-313b306e5601.png] So, It seems that when you want to draw multiple instances using the draw function, the parameter "firstInstance" should start from 0; the draw function can work adequately; is this a feature or a bug on the Windows platform? I noticed the note "firstInstance may not be supported when QRhi::BaseInstance feature is reported as not supported..." but I have checked the "QRhi::BaseInstance" feature in my platform, and it's said supported.

Further investigation on this. Some how we need to load the staticlibrary. On Linux 6.4.3 Q_INIT_RESOURCE(MyLib). This automatically loaded the libary & called qml_register type. Windows 6.61 - Q_INIT_RESOURCE(MyLib) - This gave me linker error saying that qInitResource_MyLib() is not defined. I just created the object from C++ class present in the library. It worked. We don't have to modify with extern "C". Not required.

This will be fixed in the upcoming Qt 6.8 release, and is back-ported to 6.7.2. See https://bugreports.qt.io/browse/QTBUG-125006, which adds a check for the QT_FFMPEG_PROTOCOL_WHITELIST environment variable, which the user can set to override the whitelist with their own.

@Shankarlinga-M thank you i solve that