[Interest] [QtQuick] Interaction with user from C++

[Dmitry Volosnykh]

While I cannot recommend you some 'the best book on declarative
programming', I still suggest you to read http://qmlbook.github.io

On Tue, Apr 26, 2016 at 1:27 PM Sina Dogru <sinadooru at gmail.com> wrote:

> Yes I guess I am still thinking procedural way. Do you have any
> recommendation book/documents to understand  declarative programming?
>
> Thank you for your helps.
> Sina
>
> 2016-04-26 13:07 GMT+03:00 Dmitry Volosnykh <dmitry.volosnykh at gmail.com>:
>
>> > Well the problem is ... while using QFileDialog's and QMessageBox's
>> static functions, program can continue to flow from where those functions
>> called.
>>
>> This is declarative language. Spaghetti code is unavoidable %) You'll
>> have to do a mind-shift to use QML as it was designed.
>>
>> On Tue, Apr 26, 2016 at 1:03 PM Dmitry Volosnykh <
>> dmitry.volosnykh at gmail.com> wrote:
>>
>>> > FileDialog's open function would not return the file URL while
>>> QFileDialog::getSaveFileName would return it
>>> While FileDialog.open() does not return anythying, you still able to get
>>> file's URL via fileUrl property of FileDialog instance like follows:
>>>
>>> FileDialog {
>>>   id: fileDialog
>>>   onAccepted: console.log("User selected file:", fileUrl)
>>> }
>>>
>>> Situation with MessageBox is mostly the same. This QML type provides,
>>> basically, the same functionality as its C++ counterpart. So you may
>>> perform different actions upon receiving different signals which correspond
>>> to buttons that user may press (Not suprisingly that these signals are
>>> named exactly the same as button enum's that are returned as an int result
>>> of QMessageBox::exec() method). So, here you are:
>>>
>>> MessageBox {
>>>   id: messageBox
>>>   onYes: console.log("User pressed Yes button")
>>>   onNo: console.log("User pressed No button")
>>>   onApply: console.log("User pressed Apply button")
>>>   // etc ...
>>> }
>>>
>>> On Tue, Apr 26, 2016 at 12:36 PM Sina Dogru <sinadooru at gmail.com> wrote:
>>>
>>>> Hi, Sina. You may try to wrap those C++-side static methods with
>>>>> intermediary class that is exposed to QML in a usual way. As far as I
>>>>> remember there should be some API for opening files as well as for message
>>>>> notifications. But that will require you to import QtQuick.Controls module.
>>>>> Please, refer to official documentation for more precise name of the module.
>>>>>
>>>> Hello Dmitry, thank you for respond. I think you are talking about the
>>>> FileDialog QML type and MessageBox. But my problem is, when I call a static
>>>> method of the intermediary class which calls FileDialog's open function
>>>> would not return the file URL while QFileDialog::getSaveFileName would
>>>> return it. So to do it, QML would need to call another function onAccepted
>>>> handler and it would need to know which function it needs to call.
>>>>
>>>> I mean, for example consider a situation where a C++ class process a
>>>> user input carried from QML to C++. If the user input is incorrect, I would
>>>> need to ask the user some options. So I pop up a message box which presents
>>>> the options to the user with this intermediary class. But when I do this, I
>>>> would lose the flow of the program. So when the user responds to the
>>>> message box, I would need to call another C++ function to process. But
>>>> since QMessageBox's and QFileDialog's static functions create their own
>>>> event loop and returns the data, I would be able to process new data
>>>> without loosing the current stack and flow of the program.
>>>>
>>>> So QMessageBox and QFileDialog's static functions are not need to know
>>>> on their event handlers, because they just returns the information that is
>>>> needed so program can continue from the same stack.
>>>>
>>>> Like I said, I am not so exprienced with programming. I might be
>>>> misjudging your advice or QML and C++ seperation.
>>>>
>>>>
>>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20160426/52d4e569/attachment.html>