Opened 5 years ago

Closed 5 years ago

Last modified 5 years ago

#204 closed bug (fixed)

MUIM_KillNotify doesn't work with MUIA_List_TitleClick

Reported by: Andreas Falkenhahn Owned by: Thore Böckelmann
Priority: normal Milestone: 4.0-2015R2
Component: Group.mui Version: 4.0-2015R1
Severity: minor Keywords:
Cc: OS Platform: AmigaOS4
Blocked By: Blocking:
Release Notes:

Added missing handling of MUIM_KillNotify(Obj) analog to how MUIM_Notify works to delegate removing a notification from exactly the same object it had been installed for before.



Doing a MUIM_KillNotify on MUIA_List_TitleClick doesn't remove the notification. It is still sent. See attached example code. It sets up a notification on MUIA_List_TitleClick, then removes it again. When you click on the list view's title, the notification still triggers.

Attachments (1)

main.c (5.5 KB) - added by Andreas Falkenhahn 5 years ago.

Download all attachments as: .zip

Change History (6)

Changed 5 years ago by Andreas Falkenhahn

Attachment: main.c added

comment:1 Changed 5 years ago by Thore Böckelmann

Milestone: 4.0-2015R2
Owner: set to Thore Böckelmann
Priority: undecidednormal
Status: newassigned

I can reproduce this issue. But in principle you are handling things wrong. You are setting up a notification for on attribute of List.mui named MUIA_List_XXX. But why are you doing this for the Listview.mui object lv? Why not for the real list object lv2?
If I change all the notifications to be installed/killed for lv2 instead of lv then everything is working as expected. On the one hand this means that your code is wrong. On the other hand the wrong code still exhibits a bug in MUI, because installing notifications for attributes of which an object/class doesn't know about should never trigger them.

comment:2 Changed 5 years ago by Andreas Falkenhahn

But why are you doing this for the Listview.mui object lv? Why not for the real list
object lv2?

Because that's the MUI 3.8 coding style. Just check out the examples that come with the MUI 3.8 SDK and you'll see that Stuntzi uses List.mui methods and attributes on Listview.mui objects all the time (e.g. in EnvBrowser.c, psi.c, AppWindow.c….) Thus, many developers learnt to do it the way it was done in the MUI 3.8 examples, even though it might look wrong to use List.mui methods and attributes with Listview objects… but as it is used in the 3.8 SDK all over the place, it must definitely be considered correct code and MUI 4.0 should handle it correctly.

On top of that, MUIM_KillNotify on a listview object with a list attribute actually works correctly on MUI 3.8 but *not* on MUI 4.0. So this should definitely be considered a bug. To see what I mean, just exchange MUIA_List_TitleClick with MUIA_List_Active in my example and run it on MUI 3.8… it will correctly there but on 4.0 it doesn't…

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

Component: Listview.muiGroup.mui

comment:4 Changed 5 years ago by Thore Böckelmann

Resolution: fixed
Status: assignedclosed

In 4653:

  • Group.c: restored custom implementations of MUIM_KillNotify(Obj) which work analog to how MUIM_Notify is implemented in Group.mui. For whatever reason these methods existed in the original MUI 3.9 code but not in the original MUI4 code.

The reason is that during MUIM_Notify a group object checks which of its children including itself reacts positively on GetAttr() for the desired attribute and then invokes MUIM_Notify for that object. However, since there were no implementations of MUIM_KillNotify(Obj) these methods were eventually executed for the original object and not for the object that Group class delegated the MUIM_Notify call to. Hence the notification was left alive, because MUI tried to remove it from the wrong object.
The now implemented two methods fill this gap and delegate the MUIM_KillNotify(Obj) method to child objects in exactly the same manner as MUIM_Notify is delegated.
This closes #204.

Last edited 5 years ago by Thore Böckelmann (previous) (diff)

comment:5 Changed 5 years ago by Thore Böckelmann

Release Notes: modified (diff)
Note: See TracTickets for help on using tickets.