Issue 125901 - Multi-select list box in C++ indicates item 65535 is selected when none (or multiple) are
Summary: Multi-select list box in C++ indicates item 65535 is selected when none (or m...
Alias: None
Product: App Dev
Classification: Unclassified
Component: api (show other issues)
Version: 4.0.1
Hardware: All All
: P3 Normal
Target Milestone: ---
Assignee: AOO issues mailing list
QA Contact:
Depends on:
Reported: 2014-11-25 16:56 UTC by openofficebugs
Modified: 2014-11-28 12:15 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---


Note You need to log in before you can comment on or make changes to this issue.
Description openofficebugs 2014-11-25 16:56:57 UTC
If the C++ API is used to make a multi-select list box using some of these constructs included here just for orientation

Reference<XInterface> model = xMSF->createInstance(		OUSTRING(""));
PropertySetHelper(model).set("MultiSelection", Any(multiSelection))
Reference<XListBox> result(insertByName(name, model), UNO_QUERY);

and an item selection listener is configured

Reference<XItemListener> xItemListener = static_cast<XItemListener*>(&listener);

then the listener will be called both when a selection is made and also when a second selection is made or the first is unmade by, for example, clicking on a previously selected item with the control key pressed.  When nothing is selected (or maybe more than one item is selected) the usual procedure is to indicate that item -1 is selected.  Instead, item 65535 is selected.

Somewhere in the OpenOffice code a sal_Int16 value of -1 is being converted to a sal_Int32 value in the wrong way.  As a result, the listener's code needs a work-around similar to this:

void onListSelected(int id, sal_Int32 selected) {
	bool hide = selected < 0 || selected == 65535;

It would be good to track that down and fix it.

This behavior has been observed for both Windows 7 and Fedora Linux64, but I think the problem is probably more general.
Comment 1 hanya 2014-11-25 18:20:28 UTC
0xFFFF is specified to Selected element for the argument of the itemStateChanged 
when multiple items are selected, see:
Comment 2 openofficebugs 2014-11-28 12:15:54 UTC
ItemEvent.Selected is a long, so perhaps 0xFFFFFFFF or simply -1 is meant here.  This could be a remnant from a 16-bit version since it's very unusual for a special value to be reserved in the middle of a number's range.