I have one more question about ListGroup.
The firstItemPresented events at section 30.2 stated that this event is
generated "each time the presentation status of the first item in the
itemList changes". The same goes for LastItemPresented event.
My question concerns the initialization of the ListGroup, e.g. may these
events be generated when the ListGroup is first prepared or runned.
The preparation and activation behaviours say nothing about this but I
guess that these events may rather be related to the Update behaviour used
by Activation. Perhaps a clarification in the Update behaviour could help.
IMHO, the firstItem is not presented when the ListGroup is prepared and
becomes presented when the Update behaviour is called at the end of the
activation. Consequently, I would say the an FirstItemPresented event is
generated with an TRUE eventData when the ListGroup is activated. Is this
assumption correct ?
Now suppose a listGroup with 3 cells and 3 visibles in the tokenGroupItems
attributes. At the beginning, you want the listGroup to have 5 items. It
seems that the behaviour could be different if you add the items in the
startup or in a scene IsRunning Link. If you use the startup, the ListGroup
already has 5 items when it is activated. FirstItemPresented would be
generated, but not LastItemPresented. If you use the IsRunning Link, then a
LastItemPresented True would be generated when the ListGroup is activated
and then a LastItemPresented False is generated when you add an item.
Is all this correct ?
BTW, as Technical clarification is needed about handling of unused cells
(see Resolution 4 from WG12), has someone an opinion about this. Wataru
just considered one year ago that it is an application domain problem, not
an issue. In fact, he was arguing that the author or the application domain
should be aware of this and make sure of not leaving a cell unused or not
calling an actionSlot if the cell is unused (if not desirable).
IMHO, this kind of answer is not a clarification but rather a workaround.
If you don't know how it will behave, simply avoid the possibility for this
case to occur :-). That's a safe way of doing, right, but that doesn't
clarify how an engine should behave in these cases.
Any opinion ?
To simplify things, we may say that an unused cell simply behave in the
same way that a used cell do. This is really not handy from an author point
of view but it has the advantage to limit changes in the MHEG standard.
That way, we could add a third notes at the beginning of chapter 30 like
this one :
"3 The author should be aware of possible unexpected results if the
ListGroup may have unused cell. It is his responsability to limit this case
and to prevent the token to be held by an unused cell if it is not
desirable."
What do you think ?
BR,
Emmanuel
__________________________________________________________________
Emmanuel BEUQUE mailto:ebeuque@pratique.fr
MediaServ tel: +33 (0) 2 99 64 35 64
Multimedia consultant & developer fax: +33 (0) 2 99 64 36 65