Bug 435030

Description of problem:
- RHN login name      LM-MSOC
- Company name        LOCKHEED MARTIN SPACE OPS
- Platform            x86_64
- OS                  RHEL4u3

[Environment]
RHEL4u3 x86_64 (and above) app compiled with openmotif.

[Problem Description]
Keyboard selection breaks when changing from XmMULTIPLE_SELECT mode to
XmEXTENDED_SELECT mode.
This worked fine in Motif1.2.  It does not work in any version beyond Motif1.2.

Hello David...

I've been conversing back and forth with this customer.  The situation is that
they are porting an application that is actually quite complex, from Motif 1.2.6
to OpenMotif 2.3 as delivered on RHEL4.  This application is used to communicate
with the space station.  Apparently users select commands from the list widgets
and these get sent up and 'do stuff' on the space station.   They apparently
spent some amount of time isolating the problem to the XmList widget, and
started to implement the workaround suggested by Yves Begrand of using
XmListSetAddMode(), but when they found it did not work in all cases they
started to balk at doing more.   They have subsequently found that another,
somewhat better workaround of call XtVaSetValues() to set the XmNselectionMode
to XmADD_NORMAL seems to do the trick - however, they reluctant to try any
further workarounds because of the impact that some side-effect could have (like
crashing the space station).   Despite that reluctance, they have pressed me for
a fix to the library for this issue.

I've attached a tar ball that has two versions of the program and a README:

./README
./simple_xmlist_better_kludge.c
./simple_xmlist.c


The README goes into some detail on the steps to duplicate the problem.

My analysis shows that the SetValues() method for the XmList widget changes the
selectionMode *differently* than what XmListSetAddMode() does.   It isn't clear
if this is *incorrect* or just *different*.   What the customer needs is for
someone to make a call as to whether the behavior - of the XmList switching into
ADD_MODE when policy switches from MULTIPLE to EXTENDED is a bug or a defect.

It isn't clear to me whether this should be the case, but I worked on a case in
HPUX in 2003 where a similar report was made.  The HP lab made a determination
that it was not a bug, and the customer modified their code to use
XmListSetAddMode().  Perhaps there is a bug on Linux in this area.

There are also quite a few behavioral changes from Motif 1.2 to OpenMotif 2.3
and this might be one of them.  Unfortunately, while the api documentation on
Motif is extensive, there is little documentation about differences in internals
or behavior from Motif 1.2 to Motif 2.1.

I would suggest, if it has not already been done, that SEG contact the upstream
maintainers of OpenMotif (Motifzone?  ICS? ).   Someone is going to have to
determine if this is a bug or a feature that needs to be worked around
programatically - and write a definite reason for that.   The end developer is
quite persistent and knowledgeable in some areas.  

The closest I can find to a similar bug report is:

http://bugs.motifzone.net/long_list.cgi?buglist=1276

I don't see mention of this being fixed in RH's openmotif.

Rick

Version-Release number of selected component (if applicable):

openmotif-2.2.3-10.1.el4

How reproducible:



always
Steps to Reproduce:
1. Unpack xbug2.tar.bz2
2. build 
simple_xmlist and simple_xmlist_better_kludge (Instructions in the README)
3. 

The steps demonstrating the problem are as follows:

Bring up the application, it starts in Extended select. 
Select some items.
Go to Single select. 
Select an item, reselect it (it becomes unselected), and
use the down arrow key. (The hatch marks go down). 
Press the "Set Extended" button. 
No items are selected. (This is the key behavior)

The important behavior for our app is that the item under the hatch mark
is NOT highlighted (selected) going back into extended mode from single
select under the steps outlined above. That is, when going back to extended
from single, if no item is in reverse video (explicitly selected, as opposed
to just having the hatch marks showing around a list item), then no item
will be selected once Extended mode has been set.

Now, if you press "Turn SetMode On" toggle-button, and then push "Set Extended",
we get the arrow selection to work properly in extended mode, using the
workaround OS gave us. Next, select a few items. Use the arrow down key, the
selection is propagated correctly. Now, select "Set Single", select an item,
reselect it so that it becomes unselected, but still has the hatch marks
around it.

Now, push the "Set Extended" button, and you see that the item is automatically
highlighted, i.e., selected, which causes our application to fail.

Note that the highlighting problem seems to be fixed with the new code
in simple_xmlist_better_kludge.c, and the arrows still work like they
are supposed to. However, our delivery schedule precludes us from peforming
adquate testing to make sure there are no unexpected failures with this
fix for now.

Actual results:


Expected results:


Additional info: