Opened 3 weeks ago

Closed 3 weeks ago

#356 closed bug (fixed)

Listview eats IDCMP_RAWKEY DEL down when an item is selected

Reported by: Andreas Falkenhahn Owned by: Thore Böckelmann
Priority: normal Milestone: 5.0-2017R3
Component: muimaster.library Version: 5.0-2017R2
Severity: minor Keywords:
Cc: OS Platform: All
Blocked By: Blocking:
Release Notes:

Description

Run the code, select an item, and press DEL. The program will just report the keyup event for the DEL key (i.e. 0xc6). When no item is selected, the program will report the keydown and keyup events (i.e. 0x46 and 0xc6).

On MorphOS and MUI 3.8, however, the program will report keydown and keyup events also when an item is selected so I think that the current behaviour is a bug / compatibility break and should be fixed to be consistent with MUI 3.8 and MorphOS MUI.

Attachments (1)

main.c (6.6 KB) - added by Andreas Falkenhahn 3 weeks ago.

Download all attachments as: .zip

Change History (8)

Changed 3 weeks ago by Andreas Falkenhahn

Attachment: main.c added

comment:1 Changed 3 weeks ago by Thore Böckelmann

Owner: set to Thore Böckelmann
Status: newassigned

I'll have to do some deeper investigation to find out what is really going on here. But at least I can give you the advise to better use MUIM_HandleEvent instead of MUI_RequestIDCMP() plus MUIM_HandleInput.

MUIM_HandleEvent is bound to one specific object and hence causes less overhead than MUIM_HandleInput. The passed parameters (except the additional MUI_EventHandlerNode pointer) are the same as for MUIM_HandleInput, thus it is very easy to switch from one method to the other. And MUIM_HandleEvent also works with MUI3.8 already. MUI_RequestIDCMP() is declared obsolete anyway since ages.

comment:2 Changed 3 weeks ago by Thore Böckelmann

In 6036:

  • Numeric.c, Prop.c, Scrollbar.c: don't "eat" input events which are not handled explicitly. This refs #356.

comment:3 Changed 3 weeks ago by Thore Böckelmann

In 6038:

  • Balance.c, Radio.c, Selectgroup.c: don't "eat" input events which are not handled explicitly. This refs #356.

comment:4 Changed 3 weeks ago by Thore Böckelmann

Please check again with the next nightly build. There have been several classes which simply "ate" all input events, no matter whether they really handled them or not. This definitely caused certain input events to vanish under certain conditions.

comment:5 Changed 3 weeks ago by Thore Böckelmann

Milestone: future release5.0-2017R3
Priority: undecidednormal

According to my own test all non-eaten input events are now correctly passed to any further interested object.

The key sequence "del" is converted to MUIKEY_DELETE by default. Especially classes like Scrollbar.mui were eating all MUI key input events although they really handled just a few of them. This "eating" depended on certain conditions, like the mouse hovering a scrollbar or a list with an active item. Now everything should be fine again.

But if you want to be sure to receive all input events you should really switch to MUIM_HandleEvent and add an MUI_EventHandlerNode with high priority which simply parses all the things it is interested in but always returns zero instead of MUI_EventHandlerRC_Eat.

comment:6 Changed 3 weeks ago by Andreas Falkenhahn

Yes, works now. Thanks for the fix!

comment:7 Changed 3 weeks ago by Thore Böckelmann

Resolution: fixed
Status: assignedclosed
Note: See TracTickets for help on using tickets.