Apache OpenOffice (AOO) Bugzilla – Issue 125901
Multi-select list box in C++ indicates item 65535 is selected when none (or multiple) are
Last modified: 2014-11-28 12:15:54 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("com.sun.star.awt.UnoControlListBoxModel")); ... 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); ... result->addItemListener(xItemListener); 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.
0xFFFF is specified to Selected element for the argument of the itemStateChanged when multiple items are selected, see: svn.apache.org/viewvc/openoffice/trunk/main/toolkit/source/awt/vclxwindows.cxx?revision=1595141&view=markup#l2054
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.