On 28 April 2016 at 05:02, Jérôme Godbout <jer...@bodycad.com> wrote:
> >>I wrote a simple code where a timer increment an int and a text showing
> that int in QML. And from that QML called a C++ function which blocks it.
>
> Take care, animation and rendering seem to be different thread. The Qml
> main thread should block. Maybe I don't get it what you tried here.
>
> >> How about using a promise object(Javascript concept)?
>
> It would surely help if you go with the functions inline. But those
> message box are normally part of sequence or can even be deep into an
> object function that know nothing about the caller or it's sequence status.
> Maybe promise can help here but doesn't change the real problem which is
> you need an answer before you can continue this action (like a mutex on
> that sequence, until answer is receive you want to hold in place).
>
> The current Qml async way to make this is more like signal/slot, but to
> write something that branch a lot based on the answer, make coverage hard
> to follow.
>
>
What if a promise object can be resolved by signal?
promise.resolve(dialog.accepted); // Call the "then" callback once the
signal is emitted
promise.then(function() {
// create new promise object for next async object. (save to disk?)
}).then(function() {
});;
>
> On Wed, Apr 27, 2016 at 1:12 PM, Sina Dogru <sinado...@gmail.com> wrote:
>
>> Seems like it is undefined behaviour to have QFileDialog without a
>> parent. Sometimes it becomes "ApplicationModal" but sometimes "NonModal" (I
>> experienced it with a simple code on Linux.)..
>>
>> Also Shawn warned that would block QML thread. So to try what is the
>> behaviour of engine when the thread is block, I wrote a simple code where a
>> timer increment an int and a text showing that int in QML. And from that
>> QML called a C++ function which blocks it. But seems like engine keep
>> working while it suppose to block (tried on 5.6).
>>
>> Now I need to choose between "bouncing between QML and C++" or "breaking
>> in multiple functions". Thanks for helping and acquired a vision.
>>
>> Sina
>>
>> 2016-04-26 22:32 GMT+03:00 Jérôme Godbout <jer...@bodycad.com>:
>>
>>> We have QWidgets as base window (QMainWindow) that have the QQuickView
>>> into it. For the parent, we use the QMainWindow. Maybe this explain why it
>>> work well in our case. We have some tools that are still into QWidgets
>>> (TreeView mostly with dock window, the Qml TreeView, is somewhat... painful
>>> in the current state).
>>>
>>> In the case of a Qml ApplicationWindow, I don't known if this would
>>> work, it's a QObject and not a QWidgets, the QDialog call require a
>>> QWidgets pointer as first argument. hummm, I did not realized that until
>>> now. Good point Sina Dogru.
>>>
>>> Not sure what is the behavior if the first argument is null if only have
>>> a Qml ApplicationWindow. If this work let me know, I'm curious to see if
>>> this work or not.
>>>
>>>
>>> On Tue, Apr 26, 2016 at 3:17 PM, Sina Dogru <sinado...@gmail.com> wrote:
>>>
>>>> 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
>
>
_______________________________________________
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
