Select the dynamic listitems and getting the string of lsititem

Hi All,

I displayed the dynamic list on the screen using dataprovider. Now I need to select that listitems and based on the selection for each list item, i need to go different actions for each listitem. I written the xml code for Dynamic list data display.. and how can i get the selected listitem string..

<scrollpane >
                    <list >
                        <_renderer >
                            <![CDATA[
            <listItem onfocus="contactfocus" style="layout:borderlayout" onAction="show">
               
                <container style="layout:inlinelayout(false,fill)">
                    <text >@{name}</text>
                </container>
                             
            </listItem>
            ]]>
                        </_renderer>
                        <_items >@{contacts}</_items>
                    </list>
                </scrollpane>

Please help me on this as early as possible.

Regards,

Suresh A

Could you try  replacing this

 <listItem onfocus="contactfocus" style="layout:borderlayout" onAction="show">
               
                <container style="layout:inlinelayout(false,fill)">
                    <text >@{name}</text>
                </container>
                             
            </listItem>

with

 <listItem onfocus="contactfocus" style="layout:borderlayout" onAction="show">                                
                    @{name}                                             
            </listItem>

Hi,

In the interest of others.. ,

One approach to get the widget which is currently focused and has the onMessage Event associated with it is to use FocuseManager

getFocusManager().getFocusedWidget(), Once you have widget, you could use getDataProvider() method of the widget to know the details of the dynamic data used to create the widget. In this case the name value used.

Second approach as communcated by as suresh argument[0] is always the dataprovider for the method call onMessage() call, so one could get the DataProvider directly casting argument[0] - Could kuix team verify this if this is always true.

3rd Approach is to assign the a district string to on action so that the value of the message you get is district string item.

Change the render to have a onaction value coming from the dataprovider

 <_renderer>
  <![CDATA[
   <listitem onAction="${name}" style="gap:5 0">
    <picture src="${img}"/>
    <text>@{name}</text>
   </listitem>
   ]]>
     </_renderer>

so that the string value you get onMessage would be same as what is displayed as menu item.

Followup questions to kuix team:

1. Can we not get name from the ListItem Widget itself, rather than going though DataProvider like I can get Background details etc.
2. When we changed <listitem onAction="@{name}" style="gap:5 0">
    <picture src="${img}"/>
    <text>@{name}</text>
   </listitem>

   - Observe that onAction is taking @{name} instead of ${name}.. then onAction did not had the name replacement.. I am still unclear on where to use @ and where to use $. You inputs w.r.t this case would help.

3. Is there a document to show the list of default arguments one could expect against onMessage.
4. Could you point me to the syntax of dataprovider usage in xml which support custom arguments.. and what would be the impact of such custom arguments if there already some defaults are sent by kuix. - In the current context assume that name has been declared to have few custom arguments. in such case assuming argument[0] as DataProvider is reasonable

Regards,
Raja Nagendra Kumar,
C.T.O
www.tejasoft.com

Caution, this syntax is wrong :

<listitem onAction="${name}" style="gap:5 0">

...

Properties couldn't be declared inline, use this syntax :

<listitem style="gap:5 0">

<_onAction>${name}</_onAction>

...

Tofu,

Thank you for cthe caution. We shall correct it to be in line to yoru design.

Just wanted to say in the latest release <listitem onAction="${name}" style="gap:5 0"> is also working. Not sure if this is against the design or some thoughts have gone to support it this way too.

Regards,

Nagendra

Arg ... after verification it right it works, but only for ${..} properties. Bad thing, do not use it like this, because it will be removed in the next release.

Why ? because property parsing is a quite heavy process. And it would be preferable to use it only when needed.