It can. At least in how we interpret the interaction specification in
the standard.
As we view it, an interactible can only be put into the interactive
state (InteractionStatus == true) as a result of the
SetInteractionStatus action targeted to that interactible. In that
state there are two possible ways to terminate the interaction. The
first is determined by the implementation of the interactible. This
could be a specific user input event, which as Klaus pointed out
would be caught by the interactible, or perhaps a timeout. The second
case is caused by an explicit SetInteractionStatus(false) action
targeted to the interactible.
The first case must set the InteractionStatus attribute to false,
this is explicitly mentioned in the various subclauses 'Internal
behaviours' of each sub-class of Interactible.
The definition of the InteractionCompleted event is also clear: it
must be generated each time the InteractionStatus attribute is set to
false, when it first was true.
Therefore, it seems clear to me that in both cases, one and only one
InteractionCompleted event is generated.
Since at least one of these scenarios generates this event
asynchronously, this event must be defined as asycnhronous event and
therefore must be queued with the other asynchronous events when it
is generated synchronously (by SendEvent or
SetInteractionStatus(false)).
My $0.02
Robert
,,,
(. .)
+-------oOO--(_)--OOo-------------------------------------------------+
| Robert J. Lukassen email: Robert.Lukassen@ehv.ce.philips.com |
| Philips Sound & Vision phone: +31 40 2733470 |
| ASA Lab Eindhoven fax: +31 40 2736818 |
| The Netherlands icbm: 5 25' 30'' E 51 25' 30'' N |
+---------------------------------------------------------------------+