Hyperion Entertainment Message Boards

OK, once again changed the title.
This is only happening with Ringhio pop-ups

After setting both menus in GUIPrefs to Non-Blocking only the Ringhio pop-ups get blocked

Notification pop-ups will be "locked" while one uses the Workbench pull-down menus.
That is, if one keeps the pull-down menu open (right click) the Ringhio pop-up will stay on screen (as long as one keeps the menu open, and in every state one "catches" the pop-up, i.e. nearly visible)

What i don't quite understand is, why is Notification bound to the pull-down menus?
And a (little problem) too, as every pop-up gets blocked before it can actually pop up if the Pull-down menu is open

Reproduce:
In Sys:Documentation/Ringhio/
1) Click on rx_testringhio.rexx (to make a pop-up appear)
When the pop-up is visible
2) Use either of the following pull down menus
o Workbench main pull-down (top bar)
o ANY programs pull-down (either free on screen -right mouse button on an active programs window or from Workbench's top bar)
(Tested with MUIOWB, YAM, AmigaAmp)

Now comes the inconsistency:

Start Sys:Utilities/Commodities/ContextMenus (V53.1)
Repeat the above to reproduce, but this time right click anywhere on the workbench to bring the ContextMenu up.
It will *not* lock the Ringhio pop-up, it will vanish fine after displaying.

Is this a bug?
Or could it at least be changed to act on all Pull-Down Menus (all menus?) accordingly?

I'd prefer the pop-ups not to be locked by menus, btw

Thanks a lot

AmigaOS4.1 - Update 6 (all updates)
Notifications 53.26 (30.3.2012)

Thank you very much

So i've been told by a dev that this behaviour is intended.

So, what was the explanation? Why does it behave differently for Intuition and context menus? I would really like to know.

Well it wasn't much what i've been told and i'm not that into the inner workings of AmigaOS4, but the answer was sufficient for me not to bother any longer

The answer effectively was, that the reason for the "freeze/block" (whatever it is really) is the fading effect of Ringhio's pop-up windows.
It has nothing to do with Notifications.
The fading effect will block any window (featuring it) when one has the pull-down menu button held.

And this is intended

EDIT: Please, correct me if i have something gotten wrong

Intution menus have always blocked all gfx output on the screen. This means you can stop every animation or such by opening the menu.

ContextMenus behaves differently because it is an external program, just a normal application. There is no way for an application to block gfx output like Intuition does it internally.

What yet has to be answered is why Intuition needs to block gfx output for menus or if this can be made an option in GUI prefs.

(Actually I am used to the blocking behaviour and would probably miss it.)

thomasrapp wrote:What yet has to be answered is why Intuition needs to block gfx output for menus or if this can be made an option in GUI prefs.

It already is an option - "non-blocking menus"

Why this doesn't work for fading windows is a mystery, I guess the non-blocking aspect isn't truly non-blocking, and Intuition still blocks some things when menus are active.

I believe the reason it used to block, was so programs that directly drew to the screen wouldn't overwrite the menus. Now with MENUVERIFY and big warnings not to write directly to the screen BitMap, it isn't usually a problem, as the RastPort will do the clipping and the program can stop output manually if it needs to.