Opened 3 years ago

Closed 3 years ago

Last modified 2 years ago

#333 closed bug (fixed)

frontmost public screen problems with VPDF

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

Don't use MUI's internal name of the frontmost screen as public screen name for ASLFR_PubScreenName. Since this screen will never exist it effectively makes it impossible to open an Asl requester on that screen.

Description

Summary

frontmost public screen problems with VPDF

Steps to reproduce

I found a new bug related to saving some MUI prefs in vpdf. Here is how to reproduce:

  1. Delete or move to backup location the ENVARC:MUI/vpdf.1.prefs file if it exists.
  2. Open vpdf and select the Settings/MUI menu.
  3. Go to the MUI "Screen" settings and select the "frontmost public screen" option.
  4. Save the MUI prefs and quit vpdf.
  5. Open vpdf by double-clicking the icon and select the "Project/Open FIle…" menu.
  6. Nothing happens. No requester opens. You can't load a PDF file.

Notes

Assuming that vpdf uses popasl class for a file requester, it can be mui issue. The popasl autodoc states that popasl puts the screen tag in the taglist before the program adds tags. Since it's a screen option (frontmost) that's being changed in the vpdf MUI prefs, I suspect that MUI isn't giving popasl the correct screen info; causing it to fail. That's just a guess and I haven't had time to locate another MUI program that uses popasl to see if changing the program's screen setting to 'frontmost' causes the same failure.

In meantime i choice Popasl.mui component, but can be wrong and it all can be just because of VPDF code itself.

Attachments (3)

popup_os3.lha (17.1 KB) - added by Thore Böckelmann 3 years ago.
Modified Popup demo for AmigaOS3
popup_os4.lha (6.1 KB) - added by Thore Böckelmann 3 years ago.
Modified Popup demo for AmigaOS4
Popup.c (6.2 KB) - added by Thore Böckelmann 3 years ago.
Source code of modified Popup demo

Download all attachments as: .zip

Change History (12)

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

Component: Popasl.muiforeign application
Milestone: future release5.0-2017R2
Owner: set to Thore Böckelmann
Status: newassigned

First of all, this has nothing to do with Popasl class. Popasl is responsible to open an Asl requester upon user interaction, i.e. a click on the popup button. In this case VPDF opens the requester itself and without user interaction whenever VPDF is started without any file to be opened initially.

As far as I can see in VPDF's source there is nothing suspicious or wrong there. VPDF correctly passes the window's pointer to MUI_AslRequest() when then used to determine the screen to open the requester on.

Please try the slightly modified demo application. It does basically the same as VPDF. Configure it like VPDF to open its window on the frontmost public screen. Then start it like this:

wait 5
path:to/demo/Popup

Switch to the desired screen immediately after hitting RETURN. You have 5 seconds before the demo really starts. From your description this should be enough to mimic the way you start VPDF.

Changed 3 years ago by Thore Böckelmann

Attachment: popup_os3.lha added

Modified Popup demo for AmigaOS3

Changed 3 years ago by Thore Böckelmann

Attachment: popup_os4.lha added

Modified Popup demo for AmigaOS4

Changed 3 years ago by Thore Böckelmann

Attachment: Popup.c added

Source code of modified Popup demo

comment:2 Changed 3 years ago by Roman Kargin

@Thore
Sorry, i not fully understand how you want to test it. In VPDF, i just delete vpdf prefs, then run vpdf, then setings/mui settings / screen/ frontmost public screen / save , then quit from vpdf, then run vpdf again, and then, just press in menu "open file", and then no requester popup.

But i didn't have any other screens setuped anywhere, etc. Its just as it.

With your test (i tried os4 one) , i do following: i run binary from shell, go to mui settings / screen/ frontmost public screen / save , quit from demo app. Then, i type "Wait 5" in the shell, it wait 5 seconds with holding shell. Then, after 5 seconds it give me ability to type in the shell again. I run binary again, and it runs the same as before. I not sure what i should do in 5 seconds after .. Maybe that "wait 5" should be run with something like "&" at end so i can type ?

Probably i just miss something obvious :)

Last edited 3 years ago by Roman Kargin (previous) (diff)

comment:3 in reply to:  2 Changed 3 years ago by Thore Böckelmann

Replying to Roman Kargin:

Probably i just miss something obvious :)

Put the two lines in a script and run it with C:Execute. That way you defer the start of the application a bit to give you some time to bring the desired public screen to front before the application really starts.

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

Ok, having had another look at the source I finally spotted the fault:

Look at application.c line 371 and following:

	if (filename == NULL)
	{
		filename = (char*)DoMethod(_app(obj), MUIM_VPDF_RequestFile,
						MUIV_VPDF_RequestFile_Load,
						NULL,
						NULL,
						NULL);

		if (filename == NULL)
			return FALSE;
	}

The usage of _app(obj) is wrong here, because "obj" already is the application object. The _app() macro can be used on GUI objects only, but not on instances of Application class. That is absolute non-sense.

Right above that section one finds this code:

	if (window == NULL)
	{
		window = (Object*)DoMethod(obj, MUIM_VPDF_CreateWindow);
		mode = MUIV_VPDFWindow_OpenFile_CurrentTabIfEmpty;
	}

Here the method is called correctly.

Just replace that "_app(obj)" with "obj" and the requester should open as expected. This has nothing to do with frontmost screens or whatsoever. This method call can never work, no matter how one tweaks the configuration.

I really wonder whether this menu item actually works on MorphOS. I very much doubt this…

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

It seems I thought a bit too fast. _app() does indeed work for instances of Application class as well. I just checked MUI's source in that respect. Sorry for the trouble. Using _app() on an Application object is non-sense nevertheless.

We are back at the beginning now.

I think it is up to you now to put in some debugging code and check what is happening in the MUIM_VPDF_RequestFile method. Check whether the window pointer is ok. Check whether MUI_AslRequestTags() returns success. This is your task.

I will try if I can come up with a similar demo application later.

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

Component: foreign applicationmuimaster.library
OS Platform: AmigaOS4All
Priority: undecidednormal

Ok, I found the culprit. It is MUI, or better: myself.

2011-10-24 Thore Böckelmann <tboeckel@gmx.de>
  * masterreq.c: added some code to detect missing screen or window references
    in MUI_AllocAslRequest() for the requester to be allocated. This makes it
    possible to let the requester be opened on the application's configured
    public screen without having to pass ASLFR_PubScreenName or similar tags
    explicitly.

This modification is responsible for the failure to open an Asl request if the application is configured to use the frontmost screen.

The point is that internally MUI uses a special name for this configuration and passes that name to AllocAslRequest() in case no other reference (screen or window) has been specified for MUI_AllocAslRequest(). Since ASLFR_PubScreenName has precedence over all other tags Asl will try to open its window on that screen only. If that fails (obvious, no such named screen will ever exist) the call of AslRequest() and MUI_AslRequest() will fail and no requester will be opened.

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

Resolution: fixed
Status: assignedclosed

In 5780:

  • masterreq.c: don't use MUI's internal name of the frontmost screen as public screen name for ASLFR_PubScreenName. Since this screen will never exist it effectively makes it impossible to open an Asl requester on that screen. This closes #333.

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

Just to complete the explanation. My own modified Popup demo would never have suffered the initial problem in its current form, because it allocates the requester before the application object is created. As soon as it allocates the requester after the application object is created the requester fails to open all the time when usage of the frontmost screen is configured.

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

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