You can get access to QML elements with QDeclarativeContext and its contextProperty() method.
However I'd advise against accessing QML elements from C++. Normally you'd rather do the opposite.
You can get access to QML elements with QDeclarativeContext and its contextProperty() method.
However I'd advise against accessing QML elements from C++. Normally you'd rather do the opposite.
So you would recommend that emitting a signal and then handling the rest in a qml slot stuff I wrote above?!
Or is there another (cleaner/more recommended) way?
Not necessarily.
The logic could reach a state where user input is required so it has to delegate back to the UI.
Consider a case where the UI provides a way for the user to trigger saving of data. This would very likely call into the C++ core to do the actual saving.
If that code then discovers that there is no know filename yet, it somehow has to ask the UI to ask the user for one.
I do agree of course that accessing UI elements from logic is a no-go, but signalling the UI to do something sounds very reasonable.
Cheers,
_
I think it should return information to the UI that it can't save the file because of a missing filename, the UI should ask the user for the filename and then call the save routine again. Or the logic should explicitly offer the filename to the UI and the UI should first check if it is valid or not and then call the saving routine. Doing what you suggest if of course possible and acceptable and I would probably do that myself in many cases however in theory I would still consider it bad design because of two direction coupling of components (UI had to know about logic and logic has to know about UI).
Bookmarks