vanMelle@Xerox.com (Bill van Melle) (06/07/91)
Using XView 2.0 toolkit on a Sparc under OLWM... Most user interface objects I can think of, at least in well-functioning GUI's, treat the mouse as follows: on button down, feedback about its effect is given; on mouse up, the action occurs, and ideally the user can avoid the action by releasing the button outside of the object. When it comes to XView Panels, the Button and Choice items work in this expected way. However, selection notification in a Scrolling List occurs on mouse DOWN. Thus, if I press down the mouse button inside a scrolling list and wipe up and down the list, my notify proc gets called several times, and I never have the opportunity to retract my decision. This behavior strikes me as a bug. Does anyone know why it was implemented this way? I might theorize that it was a lazy way out of dealing with multiple selection in a non-exclusive choice list, but that's not very satisfying. In any event, while I can grudgingly live with this buggy user interface behavior, it leads to another problem. In my list notify proc, I sometimes want to put up a Notice to get confirmation of the user's action. Unfortunately, when my notify proc is entered, the mouse button is still down. I put up the notice, the cursor warps to the default choice, the user lets up on the button, thinking that she has just selected an item, and this mouse up selects the default choice! From the user's point of view (if the mouse click was fast), there was a sudden flurry of display activity, and no opportunity for confirmation. My workaround for this charming behavior is to put up a Notice with no default choice, but that's really not the way things ought to work. Has anyone else dealt with this problem?
gw18@prism.gatech.EDU (Greg Williams) (06/07/91)
vanMelle@Xerox.com (Bill van Melle) writes: >Using XView 2.0 toolkit on a Sparc under OLWM... >However, selection notification in a Scrolling List occurs on mouse >DOWN. Thus, if I press down the mouse button inside a scrolling list and >wipe up and down the list, my notify proc gets called several times, and I >never have the opportunity to retract my decision. In your Scrolling List notify proc, you could check the event type by using event_is_down(event) and event_is_up(event). They return a 0/1 value if the event is the appropriate type. Thus you can do if (event_is_up(event)) { /* code here */ } In fact you can do something different on event_is_down(event) if you wanted. Thus you can do processing on both the down and up parts of a button press. I believe this will do what you want. -- Greg Williams Georgia Institute of Technology, Atlanta Georgia, 30332 uucp: ...!{decvax,hplabs,ncar,purdue,rutgers}!gatech!prism!gw18 Internet: gw18@prism.gatech.edu
vanMelle@Xerox.com (Bill van Melle) (06/08/91)
gw18@prism.gatech.EDU (Greg Williams) writes: >In your Scrolling List notify proc, you could check the event type by using >event_is_down(event) and event_is_up(event). They return a 0/1 value if > . . . >In fact you can do something different on event_is_down(event) if you wanted. >Thus you can do processing on both the down and up parts of a button press. Don't I wish. I repeat: Selection notification occurs on mouse DOWN. which I will clarify by stating that event_is_up(event) is ALWAYS false in the List notify proc. So no, I don't get a chance to wait until mouse up for my action.