[Interest] SCXML and datamodel sharing in Qt Quick and C++

Tomasz Olszak olszak.tomasz at gmail.com
Fri Dec 1 13:54:07 CET 2017


I was rather thinking about running it again once it is finished.
So currently the best way to have it consistent is to wrap data model in Qt
Object, expose params as properties. On property change update data model
value and trigger somehow current state evaluation. Is it possible? By
looking at source code it seems that sending any event  will trigger
conditions reevaluation. It is a lot better solution instead of loop in JS
and reassignment of all every data model entry.

Thanks for some clarification.

2017-12-01 13:19 GMT+01:00 Ulf Hermann <ulf.hermann at qt.io>:

> > 1. I use scxml compiler and expose compiled machine to Qt Quick.
> > 2. I use ecmascript as datamodel type. I create data entries in *.scxml
> file.
> > 3. I need to repeat those values on Qt Quick side and assign to
> StateMachine.initialValues so that they will be reset everytime machine
> starts - without it even when default values for data entries in scxml file
> are set - they are not reset.
> > 4. To change model entries (and the same evaluate transition conditions
> that have those entries in cond attribute) I need to send custom, external
> event from Qt Quick (let's call it DATAMODEL.CHANGE), which contains
> dictionary. In scxml I handle that event by assigning all entries of that
> dictionary to  corresponding datamodel entries.
>
> You cannot really stop and "deinitialize" a statemachine. If you set
> running to false, it is paused and will continue from the point where it
> stopped when you set it to true again. So, in order to reset the data model
> you have to destroy and recreate the state machine.
>
> > Is it possible by any way to define model once and share it between
> scxml state machine, Qt Quick, C++ side?
> QScxmlStateMachine has a property "dataModel" which can be accessed from
> the outside and you can manipulate properties on that. However, the
> respective methods are not Q_INVOKABLE, so for QML you'll have to wrap that
> in some other type. The lack of proper QML API for this may be a bug. In
> any case, sending an event to the state machine is a cleaner way to do
> this, as otherwise the machine will not know that the value has changed and
> will not react to the change until some other event happens.
>
> Ulf
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20171201/872bbb61/attachment.html>


More information about the Interest mailing list