On Wed, 4 Feb 1998, Richard Houldsworth wrote:
> OK, here's an attempt:
>
> 3.10 context change
> [...]
>
> BTW, "context change" and "context switch" seem to be used
> interchangeably. Perhaps standardising on "context change" across
> the document would be a good idea.
I added both contributions to the list of topics.
> > > 2. Why do asynchronous events after the context change get cleared
> > > after the elementary action, and not those before? This makes the
> > > MHEG event handling more complex, and I can't see what good it does.
> > > Wouldn't simply flushing the event queue be simpler and more
> > > predictable?
> >
> > I do not quite understand your point. The events are must be cleared
> > after the context change (the execution of the action) because the
> > action might fail and then the old scene is still valid.
>
> Section 53.3 says:
> "If such a [context-changing] action occurs, the pending asynchronous
> events whose origin is after the context switch shall be removed
> from the asynchronous event queue."
>
> My point was that events enqueued *after* the event causing the context
> switch but *before* the context switch actually happens will remain on
> the queue. I don't think this was the original intention. A suggested
> replacement wording could be:
>
> "If such an action occurs and completes successfully then all pending
> asynchronous events and ElementaryActions are removed from their
> respective queues."
OK, now I understand. Any other opinions?
Anyway, I also put this on the list.
> > > IsStopped and IsDeleted events can never trigger links in their
> > > own scene (all links are deactivated by this point), but they might
> > > inadvertantly trigger links in the target scene for completely
> > > different objects.
> > Some might, but the "IsStopped" events don't because the targets are not
> > valid anymore (with the exception that you have a general Link object
> > which triggers on every "IsStopped" event...).
>
> Some (bad) engine implementations might de-reference objects purely on
> the
> object number if the group name is not encoded. An object with the
> same number in the new scene might receive the wrong IsStopped event.
But this is a wrong implementation of an engine. We can't deal with
bad programming here... :-)
> > Hmmm, I don't know. The problem is that this is now the behaviour and
> > changing this might have great impact on existing applications.
>
> OK, changing the point of execution of synchronous events probably is
> too serious a change now, but what about specifying that pending
> synchronous events are cleared at the context change? Would this impact
> on existing applications at all?
I don't know, probably yes.
Regards,
Andreas
-- o _ Andreas Kraft (\_|_) GMD FOKUS, kraft@fokus.gmd.de, +49 30 3463-7232 T> ] [ The sky is the limit