Quote:
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 