Issue 125901

Summary: Multi-select list box in C++ indicates item 65535 is selected when none (or multiple) are
Product: App Dev Reporter: openofficebugs
Component: apiAssignee: AOO issues mailing list <issues>
Status: UNCONFIRMED --- QA Contact:
Severity: Normal    
Priority: P3 CC: hanya.runo
Version: 4.0.1   
Target Milestone: ---   
Hardware: All   
OS: All   
Issue Type: DEFECT Latest Confirmation in: ---
Developer Difficulty: ---

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.