2007/7/13, Rahul Akolkar <[EMAIL PROTECTED]>:
On 7/12/07, Ingmar Kliche <[EMAIL PROTECTED]> wrote: > 2007/7/6, Rahul Akolkar <[EMAIL PROTECTED]>: > > > > It is my interpretation of, quoted from your reference: > > > > "Note that the <invoke> element may be used to invoke an external > > SCXML interpreter to execute a different state machine. In this case, > > the external state machine acts as a set of substates of the invoking > > state. The behavior is thus similar to a complex state defined with > > <state> child elements." > > > Makes sense for sub machines! > > One would expect substates to receive all the same events. > > > I had a look at the implementation of invoke again. It apears that external > events (i.e. triggerEvents()) are used to feed events into both engines. > parentEvents() uses it to feed external events occuring at the parent into > the child engine and the child engine uses it to feed *.invoke.done into the > parents engine. > > But I have missed how the child machine may send events during execution to > its parent. If you also use external events (i.e. a triggerEvent) to send > events to the parent, how would you avoid that the same event is forwarded > again into the invoke'd machine? > <snip/> Do we need to avoid it? An event dispatched using <send> (such as your example below) would also be received similarly by a child state even if it originated there. The invoke'd machine can ignore it. > Also I have not found how events are automatically forwarded from the child > to the parent. Assume I use a <send event="foo" targettype="scxml"/> within > the child. This would let an external event occur at the child. Now - taking > the assumption that an invoke'd child machine behaves like a complex state > within the parent - I would assume that the external event occuring at the > child is also fed into the parent. > <snap/> Perhaps. The invoke section is greatly underspecified at this moment (as is acknowledged on the Commons SCXML site), my hope is that the next WD will bring some more clarity.
I agree. - Ingmar. -Rahul
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
