cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Showing results for 
Search instead for 
Did you mean: 

Community Tip - Learn all about PTC Community Badges. Engage with PTC and see how many you can earn! X

handling XUI listitem events

jsulak
1-Visitor

handling XUI listitem events

Hi Adepters,

I have a bit of a XUI problem. While I can capture the DOMActivate event on a <listbox/>, I can't do the same for any of its <listitem/> children. In other words, this works, setting target to the label of the selected listitem:

<listbox>
<script ev:event="DOMActivate" id="hitsscript" type="text/javascript">
target = Application.event.target.getAttribute("value");
</script>
...
</listbox>

But any listener attached to a <listitem/> using listitem.addEventListener("DOMActivate", listener, false) never fires.

The reason I need to do this is that I'm creating a listbox where the labels are not guaranteed to be unique. So instead of acting on listitem/@label, I want to act on listitem/@appdata, which as far as I can tell, isn't accessible from the listbox domactivate event. Also, listitem/@selected never gets set to "true," so I can't find the selected listitem that way, either.

Does anyone have any pointers?

Thanks,

James
7 REPLIES 7

Hi James--

Er, just to play devil's advocate (or something like that), what is the
use case for having a listbox with duplicate entries? How does the user
disambiguate between the first instance of "foo" and the second instance
of "foo" in the list? The fact that they would have different @appdata
values indicates that multiple instances of "foo" would not be
equivalent.

Maybe the user has some external knowledge (maybe based on order of
entries in the list) that allows them to choose the correct one. In this
case, I'd recommend constructing a label that somehow incorporates that
external knowledge, e.g. instead of "foo" for every instance of "foo",
use "Chapter 1:foo", "Chapter 2:foo" etc. (or however it breaks down).

Since @appdata is unique for the items, maybe this could be tweaked to
be user-presentable and used as listitem labels?

Other than that, I'm not sure what to advise. AFAICT you're right, the
only thing that gets updated when the user selects a listitem in a
listbox is listbox/@value, which is set to the value of the selected
listitem's @label attribute.

If you have to work around this, and can't augment the labels to
disambiguate them, the next thing I'd try is tapping into ACL using the
dlgitem_*() functions to see if you can skirt the AOM limitation that
way.

--Clay
bibach
1-Visitor
(To:jsulak)

As a last resort, if none of Clay's suggestions pan out, perhaps you
could add extra whitespace on to the end of the labels to disambiguate
them. A series of one or more zero-width spaces (if XUI handles them
correctly) should make no difference as far as the user can see, but
should let your code tell the items apart.

-Brandon 🙂


berard
1-Visitor
(To:jsulak)

I'm sort of with Clay on this, even if the user can't see the spaces,
how would they know which one to pick?

I know we get around this type of condition by putting a numeric value
before each item in the list, then when selected, we display
additional information about the node in a separate textbox.

Iterator i = newItems.keySet().iterator();
int count=1;
while(i.hasNext()) {
String appdata = (String)i.next();
String display = (String)newItems.get(appdata);

Element li = XUIHelper.createListItem(this.xuiDoc,appdata,display);

li.setAttribute("label", Integer.toString(count++) + ": " +
li.getAttribute("label"));

this.listSandbox.appendChild(li);
}

keith

On Wed, Jan 5, 2011 at 11:50 AM, Brandon Ibach
<brandon.ibach@single-sourcing.com> wrote:
> As a last resort, if none of Clay's suggestions pan out, perhaps you
> could add extra whitespace on to the end of the labels to disambiguate
> them. A series of one or more zero-width spaces (if XUI handles them
> correctly) should make no difference as far as the user can see, but
> should let your code tell the items apart.
>
> -Brandon 🙂
>
>
>
jsulak
1-Visitor
(To:jsulak)

Thanks everyone for their answers. Yeah, I realize that having non-unique list items is a bit odd, and I'll probably abandon that, but it works okay in this case because there is external context that lets the user know which one they are picking. I was surprised that XUI apparently didn't support events on list items or update listitem/@selected, and wanted to verify that with people who know more than me. For now I'll just number the items in the list, which will take care of the uniqueness problem.

Thanks,

James


bibach
1-Visitor
(To:jsulak)

I agree, Keith. My suggestion was intended as a last resort option if
the application requirements would not allow for changing the labels
to make them unique.

-Brandon 🙂


berard
1-Visitor
(To:jsulak)

Oh, sorry Brandon, I wasn't so much replying to your suggestion, so
much as the thread in general.

Very inventive solution, I'll keep that in mind for myself if I ever
need to do something like that.

keith

On Wed, Jan 5, 2011 at 12:43 PM, Brandon Ibach
<brandon.ibach@single-sourcing.com> wrote:
> I agree, Keith. My suggestion was intended as a last resort option if
> the application requirements would not allow for changing the labels
> to make them unique.
>
> -Brandon 🙂
>
>
>
bibach
1-Visitor
(To:jsulak)

On Wed, Jan 5, 2011 at 1:32 PM, Keith Berard <-> wrote:
> Oh, sorry Brandon, I wasn't so much replying to your suggestion, so
> much as the thread in general.

No worries, Keith. Smiley Happy

> Very inventive solution, I'll keep that in mind for myself if I ever
> need to do something like that.

Thank you.

-Brandon Smiley Happy
Announcements

Top Tags