FWD » Core Development » User Interface

In OE, a focused COMBO-BOX allows users to scroll through the list using the mouse wheel to change the selected item. In contrast, in FWD, rotating the mouse wheel does not affect the selection of a focused COMBO-BOX.

Razvan-Nicolae Chichirau wrote:

Vladimir, please provide a concrete example of what should happen and it doesn't.

I've made a series of tests with trunk/rev. 16323 for GUI combo-boxes in Web + Swing on SIMPLE, DROP-DOWN and DROP-DOWN-LIST modes. I could scroll in each of them with the mouse wheel in FWD. By saying in FWD, rotating the mouse wheel does not affect the selection of a focused COMBO-BOX are you refering to the fact that scrolling with the mouse wheel while a combo-box is focused should change:

• the drop-down list items
• the screen-value of the combo-box?

This one for a DROP-DOWN-LIST combo.

Because if so, 4GL only changes the list items while scrolling.

Run the following 4GL example:

DEFINE VARIABLE cb AS CHARACTER VIEW-AS COMBO-BOX
LIST-ITEMS
"item1", "item2", "item3", "item4", "item5",
"item6", "item7", "item8", "item9".
DEFINE FRAME f cb.
ENABLE ALL WITH FRAME f.
WAIT-FOR GO OF FRAME f.

This creates and enables a default DROP-DOWN-LIST combo-box.

Hover Behavior (Edit Control Area)¶

Hover the mouse pointer over the edit control area of the combo-box without opening the drop-down list.

• OE: The area highlights in light blue only while the mouse hovers; otherwise it is white.
• FWD: The area remains permanently highlighted, regardless of mouse position.

Mouse Wheel Behavior¶

Rotate the mouse wheel while the cursor is over the edit control area (drop-down list closed).

• OE: The combo-box cycles through list item values, displaying them in the edit control area.
• FWD: No reaction — nothing happens.

Note: I tested this with Swing only.

Analyzed the mouse wheel behavior on combo-boxes and implemented this override in ComboBoxGuiImpl:

@Override
public void mouseWheelMoved(MouseWheelEvent e)
{
   if (!hasFocus() || !isEnabled())
   {
      return;
   }

   boolean isSimpleComboBox = isSimpleMode();
   if (isSimpleComboBox || isDropDownActive())
   {
      // Re-route the mouse wheel event to the scroll pane.
      ScrollPane<?> scrollPane = isSimpleComboBox ? simpleListPane : dropDown.getScrollPane();
      scrollPane.mouseWheelMoved(e);

      return;
   }

   int scroll = e.getWheelRotation();
   if (scroll == 0)
   {
      return;
   }

   ComboBoxModel<?> model = model();
   int modelSize = model.size();
   if (modelSize == 0)
   {
      return;
   }

   int oldIdx = model.getSelectedIndex();
   int newIdx = oldIdx + scroll;
   if (newIdx < 0)
   {
      newIdx = 0;
   }
   else if (newIdx >= modelSize)
   {
      newIdx = modelSize - 1;
   }

   if (newIdx != oldIdx)
   {
      setNewSelection(newIdx);
   }
}

This works as it should on Swing, but doesn't at all on Web because the mouse wheel events are targeting the frame and not the combo-box. I guess this needs to also be repaired as part of this task.

The wheel event was not registered as a valid mouse action for combo-boxes on Web GUI. This fixed it:

@@ -1749,7 +1806,7 @@
    @Override
    protected int[] mouseActions()
    {
-      return new int[] { MouseEvent.MOUSE_PRESSED, MouseEvent.MOUSE_RELEASED };
+      return new int[] { MouseEvent.MOUSE_PRESSED, MouseEvent.MOUSE_RELEASED, MouseEvent.MOUSE_WHEEL };
    }

So apparently, we need to fully implement the mouseover functionality for combo boxes. After looking through other classes where this is already implemented (such as buttons), I realized it is a very tedious task and prone to errors that are not related to those that could be generated by the mouse wheel implementation.

TL;DR: We are effectively working on two issues in one task and mixing the required implementations.

Vladimir: Are you OK with implementing only the mouse wheel behavior in this task? If so, I will defer the hover implementation to a separate task.

Razvan-Nicolae Chichirau wrote:

So apparently, we need to fully implement the mouseover functionality for combo boxes. After looking through other classes where this is already implemented (such as buttons), I realized it is a very tedious task and prone to errors that are not related to those that could be generated by the mouse wheel implementation.

TL;DR: We are effectively working on two issues in one task and mixing the required implementations.

Vladimir: Are you OK with implementing only the mouse wheel behavior in this task? If so, I will defer the hover implementation to a separate task.

Yes, I am OK with this. Please, create another task for the mouse hover in COMBO-BOX issue.

10152a rev 16418 – Code Review and Testing¶

Note 1 – Small optimization in condition order¶

Replace:

if (!hasFocus() || !isEnabled())

with:

if (!isEnabled() || !hasFocus())

Reasons:

• isEnabled() is significantly faster than hasFocus().
• Disabled widgets cannot have focus anyway, so the hasFocus() check after !isEnabled() is redundant.

Note 2 – Improved readability¶

Current code block:

boolean isSimpleComboBox = isSimpleMode();
if (isSimpleComboBox || isDropDownActive())
{
   // Re-route the mouse wheel event to the scroll pane.
   ScrollPane<?> scrollPane = isSimpleComboBox ? simpleListPane : dropDown.getScrollPane();
   scrollPane.mouseWheelMoved(e);
   return;
}

Suggested replacement:

if (isSimpleMode())
{
   // Re-route the mouse wheel event to the simple list.
   simpleListPane.mouseWheelMoved(e);
   return;
}
if (isDropDownActive())
{
   // Re-route the mouse wheel event to the dropdown.
   dropDown.getScrollPane().mouseWheelMoved(e);
   return;
}

Benefits:

• Clearer and easier to read (no temporary variable + ternary operator).
• Slightly faster (avoids unnecessary variable assignment).
• Easier to debug and extend (separate conditions for simple mode and dropdown).

Both notes represent small, safe improvements with no functional change.

Unfixed issue: Mouse wheel events ignored over COMBO-BOX label area¶

When the mouse cursor is positioned over the label area (text label above the COMBO-BOX entry field) and the mouse wheel is rotated:

• OE: Mouse wheel events are routed to the COMBO-BOX widget and processed as if the cursor were over the entry field (e.g., scrolls values or changes selection).
• FWD: No action occurs.

Thanks for the review! About the mouse over the label area thing, there is this combo-box quirk: if the combo-box is focused and enabled + drop-down not active, you can scroll the combo-box with the mouse-wheel from wherever you want (mouse can be at any position on the screen, even outside its window). I didn't knew exactly if it fell within the scope of this task, as it is tied with the mouse source of the mouse event being wrong.

Vladimir: I guess we should also tackle the above in 10152a, right? If so, I think the EntryFieldGuiImpl change is obsolete as re-routing the mouse event is no longer necessary: all events will be routed directly to ComboBoxGuiImpl.

Razvan-Nicolae Chichirau wrote:

Thanks for the review! About the mouse over the label area thing, there is this combo-box quirk: if the combo-box is focused and enabled + drop-down not active, you can scroll the combo-box with the mouse-wheel from wherever you want (mouse can be at any position on the screen, even outside its window).

Great finding!

I didn't knew exactly if it fell within the scope of this task, as it is tied with the mouse source of the mouse event being wrong.

Vladimir: I guess we should also tackle the above in 10152a, right? If so, I think the EntryFieldGuiImpl change is obsolete as re-routing the mouse event is no longer necessary: all events will be routed directly to ComboBoxGuiImpl.

I see two options:

1. Close this task and create a new one specifically for the "mouse wheel anywhere" feature. In the new task, note that the changes made here are partial and may need to be adjusted or removed later.
2. Implement the full "mouse wheel anywhere" feature directly in this task.

Razvan-Nicolae Chichirau wrote:

About the mouse over the label area thing, there is this combo-box quirk: if the combo-box is focused and enabled + drop-down not active, you can scroll the combo-box with the mouse-wheel from wherever you want (mouse can be at any position on the screen, even outside its window). I didn't knew exactly if it fell within the scope of this task, as it is tied with the mouse source of the mouse event being wrong.

Note that widgets responding to wheel events without being focused is a generic behavior accross the UI in OpenEdge (as in other modern UIs).

Hynek Cihlar wrote:

Razvan-Nicolae Chichirau wrote:

About the mouse over the label area thing, there is this combo-box quirk: if the combo-box is focused and enabled + drop-down not active, you can scroll the combo-box with the mouse-wheel from wherever you want (mouse can be at any position on the screen, even outside its window). I didn't knew exactly if it fell within the scope of this task, as it is tied with the mouse source of the mouse event being wrong.

Note that widgets responding to wheel events without being focused is a generic behavior accross the UI in OpenEdge (as in other modern UIs).

You mean widget focused and the mouse pointer not being on the widget, right? Is this implemented in any way in current FWD? If not, would it be viable to check (on processing a mouse event) whether it's MOUSE_WHEEL and just apply it to the current focus if not null? I was about to do this only for combo-boxes.

Razvan-Nicolae Chichirau wrote:

Hynek Cihlar wrote:

Razvan-Nicolae Chichirau wrote:

About the mouse over the label area thing, there is this combo-box quirk: if the combo-box is focused and enabled + drop-down not active, you can scroll the combo-box with the mouse-wheel from wherever you want (mouse can be at any position on the screen, even outside its window). I didn't knew exactly if it fell within the scope of this task, as it is tied with the mouse source of the mouse event being wrong.

Note that widgets responding to wheel events without being focused is a generic behavior accross the UI in OpenEdge (as in other modern UIs).

You mean widget focused and the mouse pointer not being on the widget, right?

I mean widget not focused and mouse cursor on it.

Hynek Cihlar wrote:

I mean widget not focused and mouse cursor on it.

In our case widget is focused and mouse pointer is not on it.

Vladimir Tsichevski wrote:

Hynek Cihlar wrote:

I mean widget not focused and mouse cursor on it.

In our case widget is focused and mouse pointer is not on it.

Right, and my claim in #10152-14 doesn't hold (at least not in general).

Anyway, Razvan, if you do a system-wide change to dispatching of wheel mouse events, please test all the other widget behavior. Including the html browser widget and other converted OCXes.

It turns out this is not as straight-forward as I thought. The scrolling on a focused widget without putting the mouse pointer is not only for combo-boxes.

• Mouse-wheel event is dispatched. The source is choose initially as the focused widget.
1. If the focus is null, the event is transferred to the frame (heavier testing needs to be done here, ATM I don't know how 4GL chooses this frame from a sub-tree)
2. If the focus is on a widget that does not accept the mouse-wheel event (i.e., fill-ins, buttons), the event is transferred to its frame. It does not matter if, as a consequence of this event, the frame will be scrolled or not. The event is not propagated further up the frame parents.
3. If the focus is on a widget that accepts the mouse-wheel event (i.e., browses, combo-boxes, sliders, editors, combo-box browse columns), this will be the final source.

With these being said, I'll chose option 1 from #10152-13 and open a new task, continuing the investigation there.

Vladimir: Please review 10152a/rev. 16419.

Razvan-Nicolae Chichirau wrote:

Vladimir: Please review 10152a/rev. 16419.

The change is good.

The only remaining behaviour difference I see is:
- In OE: Shift and Ctrl modifiers suppress mouse wheel action.
- In FWD: these modifiers do not suppress it (wheel still scrolls).

That's because in 4GL SHIFT/CTRL + mouse-wheel scrolls the widget's frame, so this is again a "mouse source" problem rather than combo-box behavior.

Can we move this into Internal Testing?

Razvan-Nicolae Chichirau wrote:

That's because in 4GL SHIFT/CTRL + mouse-wheel scrolls the widget's frame, so this is again a "mouse source" problem rather than combo-box behavior.

OK. Mention this in #11211 then.

Can we move this into Internal Testing?

Yes.

• Isolated combo-box tests involving mouse-wheel
• Smoke-test on Hotel GUI + 2 customer apps

If this is enough, 10152a should be merged.

I think that's fair. I'll keep this in mind, because the trunk seems to be frozen at the moment.