At first, thanks Emmanuel for your reply.
Emmanuel wrote:
> >> 4.4. Token management in particular listGroup cases
> Well, as I asked to Tom, I even don't see how action-slots can be applied
> to cells since they are specified in the tokenGroupItems !!! (and remember
> than the tokenGroupItems can be used to fill the itemList of the listGroup
> but can be either empty). It would seem VERY CONFUSING for me that
> action-slots could be defined next to items' visible references and applied
> to cells, not
> to items !!!!
I guess, there are lots misunderstandings, here. At first, TokenGroup
doesn't define Items, but TokenGroupItems. And ListGroup defines
ItemList and a part of them, starting from the Item indicated by
FirstItem and up to the number of Positions, are mapped to
TokenGroupItems. The term "Items" in some Figures in ListGroup
implies the "Items" in the "ItemList". And in 30.1.2, the definition
of Positions implicitly says that the number of Positions shall be
equal to the number of TokenMovementTable, i.e. the number of
Positions shall be equal to the number of TokenGroupItems.
So, the initial TokenGroupItems just defines the initial mapping
between TokenGroupItems and Positions. Once you change the FirstItem,
the corresponding mapping is changed taking into account the
FirstItem, i.e. an appropriate part of ItemList is then mapped to
TokenGroupItems. However, you can make a certain Position empty by
scrolling ItemList when WrapAround is false. In this case, it's up to
the application to call the ActionSlot where no corresponding
TokenGroupItem exists.
I guess, the confusing coming from the implicit mapping between
ItemList and TokenGroupItems which is no clearly mentioned in the
standard.
> >> 6.2. Behaviour when TextData is longer than maxLength
> OK, you're right, Wataru, but let's take the last example I gave to Tom and
> he forwarded at the end of the techFAQ :
> When the entryField is initialized to a string whose length is already
> maxLength and entryPoint is 0 and overWrite is true. Characters entered by
> the user simply replace default ones. The length of the textData is always
> equal to maxLength when entryPoint is lower than maxLength.
> In this particular case, shall the engine generate an entryFieldFull event
> when entryPoint is lower than maxLength and that length remains unchanged
> (but equal to maxLength) ?
> In my opinion it should not except when entering the last char and that
> entryPoint reaches maxLength. That way, it would provide a solution to the
> example I gave but this behaviour is not specified in MHEG-5 and should be
> issued I think.
The standard says nothing for generating EntryFieldFull only at the
time of last character entered. Then, it's natural to generate
EntryFieldFull in your example. And I still believe the case you
raised is up to the application. In your case, the EntryFieldFull
doesn't well indicate the end of user input. You need some special
input to EntryField telling the end of interaction. According to the
standard, you have to provide a way to terminate the interaction of
EntryField (that's not only for the EntryField but also for Slider and
HyperText). The EntryFieldFull and the corresponding Link (triggered
when EntryFieldFull is generated and do SetInteractionStatus(XX,
false)) is not the only way to terminate the interaction. (I also
imagine that you can use GetEntryPoint() in your example. You may
terminate the interaction of the EntryField when EntryFieldFull is
generated and the EntryPoint is 2.) Therefore, I still don't think
it's a issue.
Hope to help you somehow.
Regards,
** Wataru KAMEYAMA, Graphics Communication Laboratories, JAPAN
** TEL: +81 3 5351 0181
** FAX: +81 3 5351 0185
** wak@gctech.co.jp ($B55;3!!>D!w#G#C#L(B in KANJI)