Opened 2 weeks ago

Closed 9 days ago

Last modified 8 days ago

#395 closed bug (fixed)

Move window to new screen blocks, and can't move it again. Not always.

Reported by: walkero Owned by: Thore Böckelmann
Priority: normal Milestone: 5.0-2018R4
Component: Popmenu.mui Version: 5.0-nightly build
Severity: minor Keywords:
Cc: OS Platform: AmigaOS4
Blocked By: Blocking:
Release Notes:

Description

Summary

If you hae a screen named by the same name that the "Move to a new screen" feature uses, then the app is blocked into that new created screen and can't be moved to other open screens.

Tried also with the latest nightly build MUI-5.0-20181127r6374-os4

Steps to reproduce

  1. Open odyssey and then the MUI prefs though the program.
  2. Create a screen for that called Odyssey
  3. save the configuration so that the app opens always in that screen
  4. Quit and rerun the app. From the menu object at the top right corner of the window try to move it to an other screen. This should works just fine.
  5. Try to move it to a new screen. This moves the window to a new screen names ODYSSEY.1
  6. Try to move it again to an other screen. For me this doesn't work. From this point I can't move it to any other screen.

Expected results

Expected to be move to any open screen

Actual results

The window is blocked in the new created screen. I can only close the app and reopen it to be able to move it to other screens.

Regression

Notes

This happens at AmIRC as well, which creates a new screen named AMIRC.1.
Tried Yam, but it doesn't create a new screen. I have a screen already named Yam, and if you select to move it to a new one from the menu, it remains on the same screen.

Change History (8)

comment:1 Changed 2 weeks ago by walkero

I think that the problem is more global. I tried an app that doesn't have ready made screen, which is snapit

  1. Open a MUI app, like snapit
  2. Move it to new screen
  3. Try to move it to an other open screen. This doesn't work.

I also tested the following with Yam, which had a screen assigned before, called Yam.

  1. Open on workbench MUI prefs, when Yam program was not running
  2. Renamed the Yam screen to YamTest. Save and quit MUI prefs
  3. Run Yam, which opens on workbench.
  4. Move the window to a new screen. It creates a new screen name YAM and moves in there.
  5. Try to move it to an other open screen. This doesn't work.

comment:2 Changed 2 weeks ago by walkero

And finally, this also happens with MUI prefs, which I just tested.
The steps to reproduce it are the same like SnapIt from my previous comment.

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

The "jump to new screen" feature will create a new public screen named like the application's base name plus the instance number, unless the application is a single instance application (i.e. YAM).

For example, the first instance of the Class1 demo will create a screen named "CLASS1.1", the second one will create a screen named "CLASS1.2", and so on.

After the first instance of Class1 has jumped to the screen "CLASS1.1" letting it jump to another new screen will of course fail or at least have no effect, because the 2nd new screen will be named "CLASS1.1" as well and since this one exists already and the Class1 demo is displayed there already nothing visible will happen. Letting Class1 jump to any other screen (i.e. one from the MUI screen database or any other opened public screen) of course still should work. At least it does for me.

For YAM the situation is similar. But since it is a "single instance" application the automatically created screen will be named "YAM" instead of "YAM.1".

To sum it up: from my point of view everything is working as expected. If things behave differently for you, then please create a SCREEN debug log using the debug build of muimaster.library and attach it here. Informations about the debug version can be found in the FAQ.

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

In 6376:

  • Screenspace.c, Window.c: added some more debug output when adding new screens. This refs #395.

comment:5 Changed 9 days ago by Thore Böckelmann

I think I found a possible issue. Popmenu class disposes the popup menu as soon as the right mouse button is released. However, the object which opened the popup menu has to handle the user selection afterwards and will then access a pointer returned by Popmenu class, but which has just been disposed. So if the popup menu action succeeds this is pure luck, if the referenced memory has not been overwritten by other stuff yet.

I really wonder how this could have worked for all the years without being noticed…

comment:6 Changed 9 days ago by Thore Böckelmann

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

In 6393:

  • Popmenu.c: reworked the handling of selected entries by really copying the entries instead of just remembering their addresses. This avoids accessing recently freed memory right after the popup menu has been closed. This closes #395.

comment:7 Changed 8 days ago by Thore Böckelmann

Milestone: future release5.0-2018R4

comment:8 Changed 8 days ago by Thore Böckelmann

Component: muimaster.libraryPopmenu.mui
Priority: undecidednormal
Note: See TracTickets for help on using tickets.