I'm sorry to have to open this can-of-worms again, but I'd like some
clarification of ListGroup. We have an internal disagreement here
about how to interpret the spec, and resolving it has a high priority.
First off, is this a correct description of ListGroup? -
A Class defining a fixed-size collection of 'Cells' on the screen and
an dynamically-size list of Visibles that can be mapped into those
Cells. The Token inherited from the TokenGroup base class is used to
select one Cell. The Visibles in the ItemList may be individually
selected by a separate mechanism. The mapping from ItemList to cells
may be changed by altering the FirstItem attribute, which indicates
which list item will be presented in the first cell. The Visibles
listed in the TokenGroupItems attribute are used to initialize the
ItemList.
So, working on that definition, the TokenMovementTable attribute is
used to move the Token between Cells, so the Move and MoveTo operations
affect only the Cells, and not the ItemList. To find the Visible
currently at the Cell with the Token, you have to use GetTokenPosition,
and then GetCellItem. Only the new elementary actions defined in
ListGroup have any effect on the ItemList.
However, one thing that doesn't seem clear is what happens to the
ActionSlots defined in TokenGroupItems. Where do they go, and which one
gets called by CallActionSlot?
My understanding is that the actionslots are statically associated
with cells rather than list items. Therefore, although there is a
syntactic link with a specific visible, there is no link during
execution. This interpretation appears to agree with Tom Schwengler's
Technical FAQ.
However, there is the other point of view that assumes that
the actionslots are permanently attached to the visible they are
declared with. List manipulation operations do not break this link.
As actionslots cannot be associated with items dynamically added to
the list, actionslots are only useful for ListGroups whose contents
to not change over time.
This is quite an important point as both alternatives offer
functionality that could be useful, and indeed I have seen test
scripts that use both sorts of functionality:
- Attaching actionslots to cells means you have better control
over the behaviour of the list. You can highlight cells, scroll
when you reach the end cells etc. However, much of this could also
be achieved using TokenMovedTo events.
- Attaching actionslots to visibles makes scrollable menus with
fixed content very easy. You can just define the contents in
TokenGroupItems, define the actions associated with each item in
the actionslots, and do CallActionSlot without having to do messy
offset calculations. However, the SelectItem mechanism is also
available for this sort of thing.
I'm fairly sure the first option is the intended behaviour, but:
1. I would like confirmation of this.
2. This could be added to the MTF issuelist. Some sort of explicit
explanation of this mechanism could be added to the specification.
3. Thre is no way of specifying the Actionslots for an initially
empty cell. As a work-around, I would suggest using
ObjectNumber 0 to represent 'no initial contents' in
TokenGroupItems.
I suppose this leads on to Resolution 4 in the MHEG Task-Force
issuelist: Handling of unused Cells in ListGroup objects.
Well, if actionslots are linked to cells then I would say the
behaviour is:
CallActionSlot performs as normal with empty cells. The cell is
still there, even if it has no contents, so it is valid to perform
the actions.
But it actionslots are linked to a visible then it would be:
If there is no visible under the token, then the TokenGroup
behaviour (29.4 CallActionSlot, point 3) applies. That is,it does
nothing; it does not call NoTokenActionSlots because the
TokenPosition is not 0.
Does anyone have opinions on any of this?
Regards,
Richard
-- ----------------------------------------------------------------- Richard Houldsworth, Software Engineer, Philips Research Laboratories, Redhill, RH1 5HA E-mail: richardh@prl.research.philips.com