Yes I got your points. At least there is no any bouncing between QML and
C++.
2016-04-26 20:11 GMT+03:00 Jérôme Godbout <jer...@bodycad.com>:
> We are mostly using QFileDialog and QMessageBox. Note the Qml type but the
> one from QtWidgets/QFileDialog
>
> *Q_INVOKABLE QString getSaveFileName(...); // .h*
>
>
> *QString MySingletonDialog::getSaveFileName(...) // .cpp*
> *{*
> * return QFileDialog::getSaveFileName(...);*
> *}*
>
What is the parent argument for QFileDialog? I guess this is needed to
modal window work properly?
The only way I see it is a follow (not tested just the way I see it into
> Qml Dialog):
>
> *Dialog*
> *{*
> * id: myDialog_*
> * contentItem: null*
> // Dummy content can be from anywhere or you could have a static object
> with options as property here
> * property Item myDialog1: Item { ... }*
>
> * property Item myDialog2: Item { ... }*
> // dynamic functor
> * property var acceptedCallback: null*
> * property var rejectedCallback: null*
> * onAccepted: { if(acceptedCallback) acceptedCallback(clickedButton); }*
> * onRejected: { if(rejectedCallback) rejectedCallback(clickedButton); }*
> // ... add other wanted handler for all the possible signal here
> *}*
>
> // inline callback (you can create function per sub function but that make
> the code look like a big goto mess). It's only 2 calls to interact with
> user and not branching does nothing else and it's already messy.
>
> *function myAction()*
> *{*
> * myDialog_.contentItem = myDialog_.myDialog1;*
> * myDialog_.rejectedCallback = function(button) *
> * {*
> * console.log('error');*
> * };*
> * myDialog_.acceptedCallback = *
> * function(button)*
> * {*
> // Do some stuff, need to ask something else
> * myDialog_.contentItem = myDialog_.myDialog2;*
> * myDialog_.rejectedCallback = function(button) *
> * {*
> * console.log('error 2');*
> * };*
> * myDialog_.acceptedCallback = function(button) *
> * {*
> // Do some stuff further
> // continue to dig a grave here by calling more dialog...
> * };*
> * myDialog_.open();*
> * };*
> * myDialog_.open();*
> *}*
>
That is one of the other thing that I was trying to avoid while asking the
question actually. Then there should be too many function definitions for
different kind of scenarios :S. Seems like your first solution is the best
one we have. Thank you for helping.
_______________________________________________
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
