Upd3 problem with Multiview and AmigaGuide

[tbreeden]

AmigaGuide has always been able to link to the display of a picture via a command like this:

Code: Select all

@{"Nodes Window" LINK "NodeEditWindow.ilbm/MAIN"}

(same results for jpg as well)

This worked fine in OS4.1 Upd2. It still "works", but with problems, on Upd3. What happens is that the picture file does come up, and if you hit RETRACE that works fine. But, if you try to resize the window when the picture is up, the system goes into what looks like a deepfreeze deadlock - no mouse or keyboard response - the only escape is to poweroff or reset the computer.

Since the picture often does not fit the window, the urge to resize is hard to resist. On Upd2 the resizing is not a problem (and the picture itself seems to be resized on coming up to better fit the window).

Just displaying these pictures directly in Multiview, without any AmigaGuide, works fine in Upd3, with no problem resizing.

Any chance that can be fixed? Or is AmigaGuide a "deprecated feature"?

A workaround is to use the @{".." SYSTEM ".."} to a launch of another instance of Multiview to directly display the picture. I have not figured out, however, how to get that to work satisfactorily if you are running the first Multiview on a PUBSCREEN.

Ideas?

Thanks,
Tom

[xenic]

@tbreeden
If you know the public screen that the original Multiview window opened on, you can open the new instance on the same screen by including the PUBSCREEN argument. However, it's likely that the user will have selected the public screen and there doesn't appear to be any internal way to determine the screen name from an AmigaGuide. When I had problems like this in the past I wrote a small command to change the default public screen and set the Shanghai switch before opening a program. After starting the program I called the command with no args to reset the default public screen back to workbench. In your case it might be simpler to write a small command to return the front screen name and pass it to your second Multiview instance. Relying on an external command isn't really elegant but it might make your workaround more useful. I'm thinking of something like three AmigaGuide SYSTEM commands like:

SetEnv frontname `frontscreen` (or frontscreen > ENV:frontname)
Multiview PUBSCREEN `GetEnv frontname`
UnSetEnv frontname

where "frontscreen" is your command to return the name of the frontmost screen.
NOTE: the frontscreen command is surrounded by hash marks; not single quotes.

It would be nice if Multiview had a PUBSCREEN argument option like "*" which is used by CON: to open a console on the frontmost screen. Then you could specify "Multiview PUBSCREEN *" to get multiview to open on the front screen. Lately, I've been having problems with programs opening ASL requesters on WorkBench when the program is on another public screen (like MUI-OWB). It would also be nice to have an ASL prefs item to open requesters on the front screen instead of the default public screen when a program doesn't specify a screen for the requester.

[tbreeden]

Thanks for your reply.

In your case it might be simpler to write a small command to return the front screen name and pass it to your second Multiview instance. Relying on an external command isn't really elegant but it might make your workaround more useful.

Yes, I might do that, but it would be much better if there was a system solution like that new feature you propose. (or if the MultiView/AmigaGuide bug would be fixed.)

Tom

[xenic]

Yes, I might do that, but it would be much better if there was a system solution like that new feature you propose. (or if the MultiView/AmigaGuide bug would be fixed.)
Tom

I'd like to see both . Actually, it might be handy to have a couple of new C commands like "frontscreen" and "defaultscreen" which would return the appropriate screen name for use in scripts that need to open a program or requester on a particular screen. Then a script using such a command would be guaranteed to work because the commands are part of the system.

[chris]

This is a long-standing bug which also occurs with linked plain text files (actually it happening with images might be new, not sure). I believe it has been reported on these forums already.