@Clint-Westwood said in [QBS] How to override product properties?: here has got to be some way to do it from QBS file I'm not sure. But you may ask the question on the discord chat, because there are more peoples. ;)

@JonB Thank you for your feedback. Going thorugh the existing children lists and filter the widgets in specific code is surely a bit more efficient with regards to speed, but that's not the kind of optimisation I was looking for. Some frameworks have a dirty flag for instance that triggers an evalution by the graphics system when it is due for evaluation (on 20ms ticks for instance). The polish/unpolish functions could benefit from a better documentation. I have a stylesheet only at the QApplication level, I empty all other stylesheets that are set by QtDesigner - I use the only for that. I use the same "style()" because it works and it probably is a small performance gain. I haven't tried polishing the application itself, and I suppose that is an overkill for just updating a few widgets. The default implementation of (un)polish does nothing, but QStylesheetStyle does. It seems to wrap the baseStyle(), which is likely something like QWindowsStyle or QFusionStyle which do nothing. But that's doing exactly what is needed then, only the stylesheet impacts the layout and the QStylesheetStyle handles that. QWidget::ensurePolished works recursively, but polishes only "unpolished" QWidgets in the end. Upon examination of the QStylesheetStyle code, it seems that unpolishing may not be needed. So I am removing that from the "recursive" implementation and I'll see if it's ok. It seems to avoid quite a few unnecessary operations! Update: polishing "recursively" is just enough.

@fcarney This will be configurable in Qt Creator 4.15 : https://bugreports.qt.io/browse/QTCREATORBUG-15779 https://codereview.qt-project.org/c/qt-creator/qt-creator/+/310832

@KroMignon Thanks for the extensive explanation! Now I understand what I was doing wrong. Kind regards

@KillerSmath Its working! NOTIFY did the trick. The final touch that I also included was to use a Q_INVOKABLE getModuleAt(i) instead of a Q_INVOKABLE getTextBodyAt(i); this allowed me direct access to the DataModule's property: Text{ text: dataModel.getModuleAt(index).TextBody } portion of datamodule.h: class DataModule: public QObject { Q_OBJECT Q_PROPERTY(QString TextBody MEMBER textBody NOTIFY textBodyChanged) . . . signals: void newVal(DataPiece*); void textBodyChanged(QString newText); Q_INVOKABLE method inside of the QML context class datamodel.h: Q_INVOKABLE DataModule *getModuleAt(int i); Brilliant! Thanks for the help mate. Hopefully this is helpful to others as well.

I get it. Thanks!

That's it @Eeli-K Thanks a lot

@olivierguzziIDEOL You can define Component.onCompleted for each item where you check if azert is available. Component.onCompleted: { console.log("Tab(/Rectangle/ParamsPanel) is now completed") console.log(azert) } It should be at least in ParamPanel's onCompleted. There you should be able to bind the Tab's properties dynamically.

I tried this logic (../Helpers/nestleanconstants.h): #if defined(Q_OS_ANDROID) || defined(Q_OS_IOS) #define NESTLEAN_MOBILE 1 #else #define NESTLEAN_DESKTOP 1 #endif And header of class: #ifndef NESTLEANREQUESTMANAGER_H #define NESTLEANREQUESTMANAGER_H #include <QtCore> #include <QtNetwork> #include "../Helpers/nestleanconstants.h" //Others headers #if defined(NESTLEAN_DESKTOP) #include "WebSocket/nestleanwebsocketmanager.h" #endif class NestleanRequestManager : public QObject { Q_OBJECT Q_CLASSINFO("version", "1.1") Q_PROPERTY(NestleanApplicationRequestsManager* appManager READ getAppManager) //other properties #if defined(NESTLEAN_DESKTOP) Q_PROPERTY(NestleanWebSocketManager* webSocketManager READ getWebSocketManager) #endif private: //some code #if defined(NESTLEAN_DESKTOP) NestleanWebSocketManager* m_webSocketManager; #endif public: //some code #if defined(NESTLEAN_DESKTOP) inline NestleanWebSocketManager* getWebSocketManager() { return m_webSocketManager; } #endif signals: public slots: }; #endif // NESTLEANREQUESTMANAGER_H Errors the same. I can't understand why it happens.

@Wieland I have tried what you said and I am having this error: Cannot assign to non-existent default property at line StateGroup. This is my code: MessageDialog { id: msgDialog icon: StandardIcon.Warning; standardButtons: StandardButton.Ok StateGroup { id: msgDialogStates states: [ State { name: "ActionsDialog" PropertyChanges { target: msgDialog title: qsTr("Actions Error") text: qsTr("Message.") } }, State { name: "PropertiesDialog" PropertyChanges { target: msgDialog title: qsTr("Properties Error"); text: qsTr("Another.") } } ] } } The lines with the properties: title, text, icon and standardButtons are in red as I mencioned in another post.

@Kofr Hi! If you want to be really sure (because you don't trust the docs or your code ^_^) then add something like qDebug() << "hello"; to the destructor of the model and see how often that's called.

@Dong Hello, Sorry for the late reply. Yes, you've got the essence of it. Qt's containers (QList included) are pretty smart in respect to copying, they will not copy the actual data until you change it. They are implicitly shared. This is done so you can return and copy the container many times, but in actuality internally only a pointer is reassigned and reference counter updated. When you call a non-const function on that list, Qt checks the reference counter and if more than one object is attached to the data, then and only then the data is detached (copied). When you put your list in the QVariant it is stored by value (making a shallow copy), but QVariant will return a shallow copy as well (meaning the data will not be changed, only the internal pointer reassigned and reference counter incremented). Now, for your particular case: The first line of code works, because you don't modify the list, but take an element (which is a pointer) and modify the object the list is holding reference to. This doesn't cause the list data to be copied. The second line you have, doesn't work, because you're changing the list data (assigning a new value to a list's element), which causes the list data to be detached and in practice, you're operating on a completely different set of data. Here is a reference if you're interested in the way QList and other containers manage their data, and what implicit sharing is.

They are two different types so there might have been something going because of that

You should be able to do this declaratively, by declaring either: width: image.width OR width: childrenRect.width for the "element" column. Note that this will "bind" the values. Binding is automatic in QML declarations. If you wish to bind from an imperative statement (ie, from within a JavaScript function) you can use: width = Qt.binding(function() { image.width }); Hope this helps!

Thank you for your answer but I have find my mistake. The property should be : property variant myObject: MyLib.monObject

@p3c0 Thanks!

@richardo I appreciate your input. Still I'm not sure I really like this approach that much better. As for the cycle, I couldn't see any of those usual cyclic property warnings that QML gives you in those cases. I think this cycle is already properly broken by using the correct construction in setMyCppValue: void setMyCppValue(int newValue) { if (newValue!=myCppValue) { myCppValue = newValue; emit myCppValueChanged(); } }

@Fred-Waltzer MyQMLObject will be available in all the QML files of the project. So no need to create different C++ variable.

@themts Hmmm that sounds really odd, but without the code, I don't know why it would output that error. I will say that you do not need a copy constructor. You could make a new qml type from class Thing : public QObject { Q_OBJECT public: explicit Thing(QObject* parent = nullptr); virtual ~Thing(); };