How to trap or not trap right mouse button based on location?

[Steam Ranger]

Hello. Does anyone know how to make it such that when right mouse button is pressed outside of the window, the top menu appears, and while if it is pressed within the window it gets sent as an IDCMP event.

[Minuous]

You can use IDCMP_MENUVERIFY for this; your program can then decide whether to allow the menu to open or not based on the MouseX and MouseY coordinates.

[Thomas Richter]

As said, MENUVERIFY is supposed to do that, see the intuition chapter of the RKRM Libraries. However, be prepared that MagicMenu does not handle this situation gracefully. It is a MagicMenu defect.

[kamelito]

Well the source code is available so it can be fixed.

[Thomas Richter]

The source code is not the issue. The issue is the intuition state machine any program outside of intuition cannot access or impact. Thus, MagicMenu *cannot* do this correctly by any means, that's not anyone's fault.

[Olaf Barthel]

Originally Posted by kamelito

Well the source code is available so it can be fixed.

I tried, but you can't reproduce what Intuition does when the "menu verify" operation is in effect.

Once you receive an IDCMP_MENUVERIFY event, Intuition will let the event linger until you either reply the message with your choice (show the menu, or don't show the menu) or the event's time is up in which case the default behaviour will be to show the menu.

The behaviour has an additional layer to it, too, which depends upon whether or not your window is the currently active one. Intuition is in a much better position to know when the active window changes. MagicMenu can only poll the IntuitionBase->ActiveWindow pointer and "hope" for the best.

If this weren't already enough of a challenge, Intuition can take a long view of what Windows are currently also asking for the menu verification deal on the same screen. Only one of them (the active one, if there is one) can cancel the operation, the others don't get to play yet.

This is a remarkably complex feature under the hood and, if memory serves, Intuition V33 could be accidentally tripped up by it and cause the state machine to hang.

Your chances of making this feature work smoothly depend upon using a maximum of 1 window on your own custom screen

Deluxe Paint made good use of menu verification back in the day, but you don't have to use it to get the same effect. For example, you can try to change the WFLG_RMBTRAP flag of your Window as needed, but you have to do this whenever the mouse moves and your Window is the active one. This can be a simpler alternative, but it is no full replacement for IDCMP_MENUVERIFY

[Steam Ranger]

Originally Posted by Olaf Barthel

I tried, but you can't reproduce what Intuition does when the "menu verify" operation is in effect.

Once you receive an IDCMP_MENUVERIFY event, Intuition will let the event linger until you either reply the message with your choice (show the menu, or don't show the menu) or the event's time is up in which case the default behaviour will be to show the menu.

The behaviour has an additional layer to it, too, which depends upon whether or not your window is the currently active one. Intuition is in a much better position to know when the active window changes. MagicMenu can only poll the IntuitionBase->ActiveWindow pointer and "hope" for the best.

If this weren't already enough of a challenge, Intuition can take a long view of what Windows are currently also asking for the menu verification deal on the same screen. Only one of them (the active one, if there is one) can cancel the operation, the others don't get to play yet.

This is a remarkably complex feature under the hood and, if memory serves, Intuition V33 could be accidentally tripped up by it and cause the state machine to hang.

Your chances of making this feature work smoothly depend upon using a maximum of 1 window on your own custom screen

Deluxe Paint made good use of menu verification back in the day, but you don't have to use it to get the same effect. For example, you can try to change the WFLG_RMBTRAP flag of your Window as needed, but you have to do this whenever the mouse moves and your Window is the active one. This can be a simpler alternative, but it is no full replacement for IDCMP_MENUVERIFY

What would you recommend the use case for each method would be? I've been doing a bit of reading and have also found the two methods, but where would it be best to use each one? What are the upsides and downsides of each method?

Also, why do you say "Your chances of making this feature work smoothly depend upon using a maximum of 1 window on your own custom screen"? Why is this so?

[Olaf Barthel]

Originally Posted by Steam Ranger

What would you recommend the use case for each method would be? I've been doing a bit of reading and have also found the two methods, but where would it be best to use each one? What are the upsides and downsides of each method?

For me the downside to IDCMP_MENUVERIFY is that you have a more complex tool to contend with.

Intuition may notify you before it will transition into the menu rendering state. You will have to decide whether to let the menu rendering continue or not, you will also have to do this quickly before the default behaviour catches without you having a chance to make it something else. You may receive this message at a point when your window is no longer active (all input events are asynchronous by nature, as is Intuition's remit to react to these events), which makes this even more "unreliable".

I struggle to find a compelling use for the IDCMP_MENUVERIFY feature, really, except that Intuition is doing much of the work for you which you would otherwise have to do all by yourself, should you rely upon the WFLG_RMBTRAP flag to be set/cleared as needed.

Tinkering with WFLG_RMBTRAP is more easily accomplished. You clear the flag when the mouse position within your window requires that a right mouse button click reveals the menu, you set the flag otherwise. You do need to enable mouse movement reports with IDCMP_MOUSEMOVE just so that you can change the WFLG_RMBTRAP flag as needed. Note that due to how the events are processed, the user may click the right mouse button and fail to see the menu appearing. If the mouse is moved quickly, your program may not be able to update the WFLG_RMBTRAP flag state in sync with where the mouse pointer is when you process the event.

Also, why do you say "Your chances of making this feature work smoothly depend upon using a maximum of 1 window on your own custom screen"? Why is this so?

Only one single Window of a screen can have control over whether the menu is to appear if you use IDCMP_MENUVERIFY. If there is more than one, you may still see these events but may have no control over them if your Window is currently inactive.

The use IDCMP_MENUVERIFY worked very well for programs such as Deluxe Paint, which only ever opened a single Window on the Screen for painting or using the tool box/magnifier, etc.

[Steam Ranger]

Originally Posted by Olaf Barthel

For me the downside to IDCMP_MENUVERIFY is that you have a more complex tool to contend with.

Intuition may notify you before it will transition into the menu rendering state. You will have to decide whether to let the menu rendering continue or not, you will also have to do this quickly before the default behaviour catches without you having a chance to make it something else. You may receive this message at a point when your window is no longer active (all input events are asynchronous by nature, as is Intuition's remit to react to these events), which makes this even more "unreliable".

I struggle to find a compelling use for the IDCMP_MENUVERIFY feature, really, except that Intuition is doing much of the work for you which you would otherwise have to do all by yourself, should you rely upon the WFLG_RMBTRAP flag to be set/cleared as needed.

Tinkering with WFLG_RMBTRAP is more easily accomplished. You clear the flag when the mouse position within your window requires that a right mouse button click reveals the menu, you set the flag otherwise. You do need to enable mouse movement reports with IDCMP_MOUSEMOVE just so that you can change the WFLG_RMBTRAP flag as needed. Note that due to how the events are processed, the user may click the right mouse button and fail to see the menu appearing. If the mouse is moved quickly, your program may not be able to update the WFLG_RMBTRAP flag state in sync with where the mouse pointer is when you process the event.



Only one single Window of a screen can have control over whether the menu is to appear if you use IDCMP_MENUVERIFY. If there is more than one, you may still see these events but may have no control over them if your Window is currently inactive.

The use IDCMP_MENUVERIFY worked very well for programs such as Deluxe Paint, which only ever opened a single Window on the Screen for painting or using the tool box/magnifier, etc.

Thanks for the summary. I realised the RMB trap is the only one that would work for me. I'm making a system where you have context menu zones in the window, so clicking on different things give different menus, but there are parts of the window that may have no zone and instead show the screen menu, so I will need to manually change the thing.

Again, thanks for your help.

[Bruce Abbott]

Originally Posted by Olaf Barthel

I struggle to find a compelling use for the IDCMP_MENUVERIFY feature

The purpose of menuverify is so an application can prepare for a menu operation. For example it might be rendering directly to the screen, which could corrupt the menus or vice versa. It shouldn't be used to block menu operations - that's why there is a timeout in KS2+.

Reasons to Use Menu Verify

The primary purpose of the menu verify feature is to arbitrate access
to screen resources. There are really only two screen resources that
an application might need to use directly, the palette and the bitmap.

Some applications need as many pens as possible, so they change the
color values of the pens that Intuition uses to render the menus. This
can present a problem if the application happens to alter the menu pen
colors so that the menu's foreground color is difficult (if not
impossible) to see against the background color. The menu items will
be unreadable to the user.

To prevent this problem, the application has to restore the original
pen colors when the user pulls down the menu. The application can do
this using menu verify. When the user hits the menu button, Intuition
sends the application a menu verify message. When the application
receives this message, it restores the menu colors and then returns the
IDCMP_MENUVERIFY message so Intuition can properly render the menus.
When the menu operation is over, Intuition will send a ``conclusion''
IDCMP message...

Another reason to use menu verify is to arbitrate rendering access to
an Intuition Screen's bitmap. While Intuition is displaying the menus,
the application must not render directly to the screen's bitmap because
the application could draw over the menus. The application must wait
until the menu operation is over to resume rendering.

If you don't want the menus to activate when pressing the right mouse button then use rmbtrap. With rmbtrap intuition doesn't even think about operating the menus, it just passes the mousebutton message on to you.

To use WFLG_RMBTRAP as an alternative to menu verify, the application
tracks mouse movement using IDCMP_MOUSEMOVE. While the pointer is
outside of the screen's title bar, the application makes sure the
WFLG_RMBTRAP flag is set. If the user hits the right mouse button
while WFLG_RMBTRAP is set, Intuition sends the application a mouse
button event. While the pointer is inside the screen's title bar, the
application makes sure the WFLG_RMBTRAP flag is clear. If the user
hits the right mouse button while WFLG_RMBTRAP is clear, Intuition
generates a normal menu event for the window.

WFLG_RMBTRAP is an exception to most fields in Intuition structures
because it is legal for an application to directly modify this flag.
Note that this change must take place as an atomic operation so that
Exec cannot perform a task switch in the middle of the change. If you
are unsure your compiler will do this, use a Forbid()/Permit() pair to
prevent a task switch.

Will I Ever Need to Cancel a Menu Operation?

When the active window receives an IDCMP_MENUVERIFY message, it has the
option of cancelling the menu operation. Although this feature may
have some possible uses, for the moment there is no recommended use for
it

[Thomas Richter]

Originally Posted by Steam Ranger

I'm making a system where you have context menu zones in the window, so clicking on different things give different menus, but there are parts of the window that may have no zone and instead show the screen menu, so I will need to manually change the thing.

First of all, I would consider it "not nice" if a program breaks with the user interface style that is otherwise consistent with all other programs. If there are special right-click menus in one particular program where a menu opens in a place intuition does normally not open a menu then that makes the user experience quite inconsistent.


Second, the problem with the RMB trap is that at the time you change the flag, it may already be "too late" and intuition may already be in the progress with rendering the menu, so you cannot be sure that you do not get a MENUPICK instead of a mouse button event. MENUVERIFY excludes that by intuition explicitly asking *at the time it processes the event* what precisely it should do. So the concept of MENUVERIFY is in that sense a lot better integrated into the intuition system.

[aros-sg]

It's better to use WLFG_RMBTRAP. The docs themselves discourage use in most cases, except the rare cases like where programs really want to render directly to screen bitmap (instead of window) or things like paint programs which change palette and menu could be unreadable, so the program needs need to temporarily change palette while menus are open to make it readable.