OK, many thanks for this further information about listGroup. I think I now
understand your opinion about the listGroup class.
Anyway, may I make a suggestion ? I think this explanation should
definitely be in the standard if it is the truth. I mean that it's perhaps
clear for you because you have perhaps participated to the MHEG definition.
For me, it is rather confusing because of the end of section
"30.1.3.ItemList" :
"At preparation, this set is initialised to the set of references listed in
the <I>TokenGroupItems</I> attribute."
Even if I understand well that item in listGroup is item of the itemList,
this particular sentence make confusion for me because it tends to say that
the initial set of references of the itemList can be specified by the
tokenGroupItems and the standard never says that the number of
tokenGroupItems MUST BE equal to the number of cells (positions).
Suppose an author who wants to make a listGroup with 5 cells and 8 known
items. When reading the standard, he is encouraged to use the
tokenGroupItems set of visible to fill the itemList with its 8 items. Well,
but it is impossible following what you say because the tokenGroupItems
must have 5 items, not more, not less. If I understand well, he should
instead fill the tokenGroupItems with the first 5 items he know. Then he
has to add the 3 further items in the startup using AddItem actions. Am I
right ?
Now, suppose that he doesn't know how many items he will have in its 5
cells listGroup. (the items should come from a regularly updated database
using some program). He wants to build an empty listGroup but he would also
like to use some action-slots. Is it possible ? How ? TokenGroupItems must
define object-reference. Theoritically, tokenGroupItems can not be filled
with null for visible. Consequently, should he fill it with useless visible
and then delete all items in the startup ?!!! Perhaps null should be
accepted in the tokenGroupItems definition...
>> >> 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.
OK, you seem to agree with Tom on this that an EntryFieldFull event shall
be generated everytime a new char is entered and the length of textData is
equal to or higher than maxLength, even if the length of textData is
unchanged (i.e. overwrite is true, entryPoint < length).
If it is right and OK for all MHEG group members, then I suggest that the
text of the standard at section "43.2.EntryFieldFull" should be changed a
bit.
Now it is :
"... it is generated when the number of characters in the EntryField
reaches MaxLength."
It should rather be :
"... it is generated each time a character is entered, when the new number
of characters in the EntryField is higher than or equal to MaxLength."
Because, in my opinion, "reaches" means that the event is generated only
once when the number of chars was lower than MaxLength and becomes equal to
MaxLength. But perhaps I don't understand well all subtleties of the
English language...
Best regards.
__________________________________________________________________
Emmanuel BEUQUE Email: ebeuque@pratique.fr
mediaServ tel: +33 (0) 2 99 64 36 64
Multimedia consultant & developer fax: +33 (0) 2 99 64 36 65
__________________________________________________________________