Opened 4 years ago

Closed 4 years ago

Last modified 4 years ago

#134 closed bug (fixed)

Hide Single Tabs option - adding/deleting Pages when Clicktab is not currently visible

Reported by: Richard Lake Owned by: Thore Böckelmann
Priority: normal Milestone: 4.0-2015R2
Component: Title.mui Version: 4.0-2014R5
Severity: minor Keywords:
Cc: Andreas Falkenhahn OS Platform: All
Blocked By: Blocking:
Release Notes:

Description

Summary

I have given you a link below to an executable of my new MUI Builder application as this is a much better way to explain the problem.

http://www.lakemarketing.co.uk/jack_uploads/MUIBuilder

Hopefully the EXE will open as is you won't need any dependancies, if something is missing please do let me know.

Steps to reproduce

  1. In MUI Settings turn on Groups/Hide Single tab.
  1. Run the MUIBuilder application, on the second tab, you can Add new windows to the interface, doing so adds a listitem to the above listview the code also adds a Tab to the interface. This new Tab be found under the main tab list titled Layout.
  1. Now return to the Windows tab, now delete all the Windows apart from the one at the top which is not allowed to be removed. As you delete the second tab to leave one remaining the screen corrupts as per the screenshot shown.
  1. At this point, adding pages to the interface also causes the application to exhibit incorrect behaviour.

Expected results

Screen not to corrupt when Closing/deleting pages of a Clicktab gadgets which is currently out of view when the MUI Setting 'Hide single tab' is enabled. Looks like an oversight.

Actual results

GUI corruption. See attached screenshot.

Regression

Notes

I hope this makes sense.

Attachments (7)

Jack_ScreenCapture5.png (116.1 KB) - added by Richard Lake 4 years ago.
Playing around adding and removing windows causes this unwanted behaviour
nested_registers.c (12.1 KB) - added by Thore Böckelmann 4 years ago.
nested_registers demo source
nested_registers_os3.lha (12.3 KB) - added by Thore Böckelmann 4 years ago.
nested_registers demo AmigaOS3
nested_registers_os4.lha (6.8 KB) - added by Thore Böckelmann 4 years ago.
nested_registers demo AmigaOS4
more-recent-example.png (119.4 KB) - added by Richard Lake 4 years ago.
HW_Nested_registers.lha (1.5 MB) - added by Richard Lake 4 years ago.
Crashlog_HWNestedRegister_2015-03-03_06-06-42.txt (26.3 KB) - added by Thore Böckelmann 4 years ago.
Crashlog of Hollywood demo

Download all attachments as: .zip

Change History (32)

comment:1 Changed 50 years ago by Richard Lake

Status: pendingnew

Changed 4 years ago by Richard Lake

Attachment: Jack_ScreenCapture5.png added

Playing around adding and removing windows causes this unwanted behaviour

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

Is it possible to provide an 68k binary for AmigaOS3? Or is the new MUIBuilder intended to run on AmigaOS4 only?

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

Resolution: duplicate
Status: newclosed

This seems to be the same issue as described in #15. Anyway, an AmigaOS3 build of MUIBuilder would definitely help to resolve this issue.

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

comment:3 Changed 4 years ago by Richard Lake

Latest 2015R1 for OS4 unfortunately does not fix this bug, corruption still present as per original attachment.

comment:4 Changed 4 years ago by Richard Lake

Resolution: duplicate
Status: closedreopened

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

Component: undefinedTitle.mui
Milestone: MUI 4.0-2015R2
Priority: undecidednormal
Status: reopenedpending

I think MUI builder is doing something wrong here, or at least isn't doing enough. I prepared a small demo application which adds a new page to a Title.mui object on a different page. This one works without any problem. So you better check if you surrounded all dynamic changes to your objects by the mandatory MUIM_Group_Init/ExitChange pairs.

Changed 4 years ago by Thore Böckelmann

Attachment: nested_registers.c added

nested_registers demo source

Changed 4 years ago by Thore Böckelmann

Attachment: nested_registers_os3.lha added

nested_registers demo AmigaOS3

Changed 4 years ago by Thore Böckelmann

Attachment: nested_registers_os4.lha added

nested_registers demo AmigaOS4

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

If possible then please provide a minimal demo application yourself which exhibits the issue. MUIBuilder is a bit too big for this purpose.

comment:7 Changed 4 years ago by Richard Lake

Thanks I have noted your reply, when I have a little time I will look into this further.

comment:8 Changed 4 years ago by Richard Lake

I have added the Init/ExitChange pairing (it was missing), however this doesn't seem to have made a difference. Like you say it looks like I will have to prepare a minimal demo exhibiting this issue. Please can you add Andreas to this ticket as well, thank you.

Changed 4 years ago by Richard Lake

Attachment: more-recent-example.png added

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

Cc: Andreas Falkenhahn added

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

Milestone: MUI 4.0-2015R24.0-2015R2

Milestone renamed

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

Any progress here?

comment:12 Changed 4 years ago by Richard Lake

Hi, thanks for the reminder, I will do what is required this week.

comment:13 Changed 4 years ago by Richard Lake

Right, I've created a stripped down version, similiar to the Nested Register exe you kindly attached.

Now, I've observed a few things, 1, the visual mess still occurs, 2, if I use InitChange and ExitChange before and after the method AddPage is called Hollywood complains that that 'InitChange' is not recognized by this class, 3 if I comment out the InitChange/ExitChange pairing the program continues to flow.

So if Andreas can please reply with some input it would be most appreciated.

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

Replying to djrikki:

Right, I've created a stripped down version, similiar to the Nested Register exe you kindly attached.

Thanks for not sharing it with us :( This way you really make sure that nobody will be able to help you.

Now, I've observed a few things, 1, the visual mess still occurs, 2, if I use InitChange and ExitChange before and after the method AddPage is called Hollywood complains that that 'InitChange' is not recognized by this class, 3 if I comment out the InitChange/ExitChange pairing the program continues to flow.

In general wrappers like HollyWood should make no assumption about which method can be called for which kind of object. Although something like MUIM_Group_Init/ExitChange is suitable for groups only it also might be possible that other non-group classes use it at some day in the future for whatever reason.

All public MUI method IDs are unique. If a class doesn't know how to - or doesn't need to - handle a specific method it will pass it to its parent class and eventually up to rootclass which in turn does nothing with unknown methods except to return zero. This causes absolutely no harm except that some additional CPU cycles are spend to do exactly nothing.

Changed 4 years ago by Richard Lake

Attachment: HW_Nested_registers.lha added

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

I finally managed to try your nested tabs demos myself. But for me everything is working perfectly. And there are no complaints from Hollywood about unrecognized methods.

Do I have to do anything else than just starting the demo with "hollywood main.hws" and then press the "Add window" button?

comment:16 Changed 4 years ago by Richard Lake

Yes, start it, then click the second tab along the top first, and then come back to the first tab and then press the Add Window button - it corrupts at that point for me.

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

No problem here on AmigaOS3. I suppose compiled Hollywood programs behave exactly like those run by Hollywood "online". Andreas?

Is it possible that your demo archive is missing some stuff? Where is that "AddPage" method defined which you use to add new pages? I cannot find it anywhere. And the MUIM_Group_Init/ExitChange pairs you mentioned before are missing, too.

Honestly, if you want this issue to be fixed then you must supply complete examples and just half the stuff which omits all the details about which you tell that are not working for you.

Version 0, edited 4 years ago by Thore Böckelmann (next)

comment:18 Changed 4 years ago by Richard Lake

Yes I too would appreciate some input from Andreas so that we may put things to bed.

As for my demo archive, the executable runs under AmigaOS4+ only, the Addpage is within main.hws:

Function p_AddWindow()

mui.DoMethod?("availablewindows","insert","bottom","new window")

Local xml$

Local count = mui.Get("availablewindows","entries")-1xml$ = "<vgroup id=\"windowtab-WIN" .. count .. "\">\n"

; this will need to be either New Window or Loaded in at some point in the future, atm just stick with loading this dataxml$ = xml$ .. "<listtree id=\"winlayout-" .. count .. "\" notify=\"active;doubleclick\" cyclechain=\"true\">\n"xml$ = xml$ .. "<node id=\"win" .. count .. "-vgroup0\" name=\"New Window " .. count .. " (VGROUP)\" open=\"false\">\n"xml$ = xml$ .. "<item>test</item>"xml$ = xml$ .. "</node>\n"

xml$ = xml$ .. "</listtree>\n"

xml$ = xml$ .. "</vgroup>"

debugprint(xml$)

mui.CreateObject?(xml$)

;mui.DoMethod?("evo_window-pages","initchange")mui.Set("windowtab-WIN" .. count,"title","New Window " .. count)

mui.DoMethod?("evo_window-pages","AddPage","windowtab-WIN" .. count)

debugprint("create tab with id windowtab-WIN" .. count)

Return(newwindow)

EndFunction

If I were to uncomment the InitChange line, I get an error from HollywoodPlayer:

"Method 'initchange' not recognized for this! File: main.hws (current line: 45 In Function: DoMethod).

Under AmigaOS 4, compiled under Holllywood 5 (or 6) this is bug happens occurs every time without fail.

I am well aware of the reasons why to use the InitChange/ExitChange pairing except the AddPage method as implemented in MUI Royale as can plainly be seen as handled somewhat differently.

Last edited 4 years ago by Richard Lake (previous) (diff)

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

For me the AmigaOS4 binary just crashes when I try to add a new page. The crashlog contains absolutely no reference to MUI. Hence I must say MUI is out of the scope here.

Changed 4 years ago by Thore Böckelmann

Crashlog of Hollywood demo

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

Furthermore you are doing an MUIM_Group_InitChange, but no MUIM_Group_ExitChange. These methods must be used in pairs!

There definitely seems to be a difference between a compiled binary and an application run "online" by Hollywood. This difference should be eliminated first. Otherwise the results cannot be compared in any way.

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

Ok, a big excuse and "Sorry!" from my side.

I always forgot to enable the "Hide single tabs" option and hence everything was working perfectly for me. With that option active I also get the effect that the nested title group on the second page becomes visible on the first page after adding a new tab, even on AmigaOS3 and with running the demo "online" with Hollywood.

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

In 4568:

  • Title.c: do a full relayout with the "Hide single tabs" option active only if the object is currently visible and not located on a currently invisible page (i.e. nested registers). The layout is still not correct, but at least the object does not become visible on the wrong page. This refs #134.

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

Owner: set to Thore Böckelmann
Resolution: fixed
Status: newclosed

In 4569:

  • Title.c: adding a second tab to a currently invisible title object (i.e. on a different nested title object page) with the "Hide single tabs" option no longer redraws that object but only performs the usual setup steps. This closes #134.

comment:24 Changed 4 years ago by Richard Lake

Good morning, well I am very thankful that we finally got there in the end! I do recognise and see that you are clearly devoted to MUI and ensuring that bug reports are dealt with swiftly given the strange hours that you come online to review and fix this stuff! I can fully appreciate how the oversight came about. As always, I look forward to a public release later this year.

Note: See TracTickets for help on using tickets.