Opened 4 years ago

Closed 4 years ago

Last modified 4 years ago

#247 closed bug (fixed)

Adding register tabs into arbitrary positions

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

Description

When using MUIM_Group_AddHead or MUIM_Group_Insert to insert register tabs (and their title objects) into a position different from the tail of the list, it doesn't really work. OM_ADDMEMBER works fine, though. Could it be that tab pages can currently only be added to the tail of the list? In that case, it would be good if support could be extended to allow insertion into arbitrary positions.

Change History (7)

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

Component: Register.muiTitle.mui
Owner: set to Thore Böckelmann
Priority: undecidednormal
Status: newassigned

I just changed the OM_ADDMEMBER calls for adding the tab and the page in the Titles demo to MUIM_Group_AddHead and all new tabs are correctly added on the left side instead of the right side of the Title object. I also did some further work to save references to the first tab and page to make MUIM_Group_Insert work and then all new objects are correctly added right after the first tab. So this is definitely working.

Keep in mind that tabs and pages must be added in the same fashion. If you add the tab object using MUIM_Group_AddHead you must do the same for the page object. Otherwise the order of tabs and pages is messed up.

And I suppose we are talking about Title class here, not Register class, correct? Although it is possible to do some dynamic page adding/removal with Register class this should usually done with Title class now.

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

Component: Title.muiRegister.mui
OS Platform: undefinedAll

Having read the description some more times it becomes more clear to me that you are indeed really talking about Register class instead of Title class.

Since Register class is now a wrapper for Title class it becomes obvious to me that methods like MUIM_Group_AddHead cannot work correctly, because from the outside point of view Register class doesn't know about the Title object being the group's first object. More important even, the Title object must stay at that position and simply passing MUIM_Group_AddHead to Group class will destroy this necessity.

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

Resolution: fixed
Status: assignedclosed

In 4906:

  • Register.c: catch MUIM_Group_AddHead and all kinds of "reordering" methods like MUIM_Group_Sort to keep the embedded Title object at the head of the child list. This closes #247.

comment:4 Changed 4 years ago by Andreas Falkenhahn

Not sure if this really needed this fix. I obviously made a mistake by using MUIM_Group_AddHead to add a new page which shifted the title object down and left a mess. I now modified the code to use MUIM_Group_Insert to leave the title object in its place and this is indeed working fine. So you might want to revert this fix because MorphOS doesn't "patch" MUIM_Group_AddHead in this case either.

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

Replying to afalkenhahn:

Not sure if this really needed this fix. I obviously made a mistake by using MUIM_Group_AddHead to add a new page which shifted the title object down and left a mess. I now modified the code to use MUIM_Group_Insert to leave the title object in its place and this is indeed working fine. So you might want to revert this fix because MorphOS doesn't "patch" MUIM_Group_AddHead in this case either.

No, the former behaviour was definitely wrong. An application using Register class only knows about its own page objects and can respect only these. Any further objects being added to a Register object are beyond the application's scope. Adding pages at the front using MUIM_Group_AddHead must always work, no matter if Register class is a wrapper for Title class or not. Hence Register class must take care of these methods if it adds further objects along with the page objects. How do you old applications using Register class to react if suddently an additional object appears that is no page object at all?

If MUI on MorphOS fails to respect this, then it is buggy from my point of view.

comment:6 Changed 4 years ago by Andreas Falkenhahn

Well but if you really aim for complete opaqueness of the title object, then you would also have to patch MUIA_Group_ChildList to not return the title object but this would break MUI Royale because MUI Royale expects a title object as the first child.

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

That is not possible. An object can belong to one list only. Hence MUI cannot create a copy to return that one instead of the original list. The restriction of the methods is just a kind of self protection against accidental object/page reordering which would render the whole Register object completely unusable otherwise.

Note: See TracTickets for help on using tickets.