bryce@hoser.berkeley.edu (Bryce Nesbitt) (10/04/87)
A person I am working with is producing a program that uses MENUVERIFY. The
"Oh, you mean you can't call DOS with that on." problem was fixed with a
little re-education. However VERIFY functions still cause a basket full of
headaches.
The application he wants is to use position sensitive right mouse button
selects, Deluxe Paint style. The current setup uses MENUVERIFY and cancels
the operation if not over the menu bar. (Can you say "yick!"?) MENUVERIFY
is a lot of tool and a lot of trouble for a ?simple? need.
It would like to be recoded *not* to use verify. This does not turn out to
be as easy as it may sound. I did come up with a way and a test program...
a way for which the word "Kludge" was invented. Here's the comic story:
Set RMBTRAP.
When a RMB message is received, check the position.
If below the Window's Screen's title bar height handle internal.
Else we just screwed up a menu operation!! Unset RMBTRAP then send a
press-relese pair of RMB events to the input.device.
Reset RMBTRAP after the menu is used.
This works. In fact, it has a great feel to it. If the program is too
busy to respond to the pulldown you know immediatly. >Keep holding it, and
the menu will come down when the program is ready to listen<. Best of all
you can pull the mouse away and do something else (a feature MENUVERIFY
does not offer). Fantastic!
The theory of operation is ugly, however. So ugly that the program will
probably be left with verify. As a long shot another task could handle it.
Neither solution produces end results as nice as the above, or works really
well with what I understand of this particular program's structure.
What else can be done?
What are the (truths or) consequences?
On the ugly index, where does the above fit?
|\ /| . Ack! (NAK, ENQ, SYN)
{o O} .
(") bryce@hoser.berkeley.EDU -or- ucbvax!hoser!bryce
U How can you go back if you have not yet gone forth?derek@puff.wisc.edu (Derek Zahn) (10/06/87)
In article <4145@zen.berkeley.edu>, bryce@hoser.berkeley.edu (Bryce Nesbitt) writes: > The application he wants is to use position sensitive right mouse button > selects, Deluxe Paint style. > > It would like to be recoded *not* to use verify. > > Set RMBTRAP. > When a RMB message is received, check the position. > If below the Window's Screen's title bar height handle internal. > Else we just screwed up a menu operation!! Unset RMBTRAP then send a > press-relese pair of RMB events to the input.device. > Reset RMBTRAP after the menu is used. > > The theory of operation is ugly, however. Not as ugly as many such things; in fact, it seems rather supported. I have been wondering about this very question recently and have been using (temporariy at least) the following solution. It is also ugly and perhaps not strictly "legal", but it seems to work and it is easy... First, I have MOUSEMOVE set (I need this for something else anyway). Then, the relevant chunk from the IDCMP loop looks something like: case MOUSEMOVE: if(message->IDCMPWindow->WScreen->MouseY > TITLEHEIGHT) { Forbid(); message->IDCMPWindow->Flags |= RMBTRAP; Permit(); } else { Forbid(); message->IDCMPWindow->Flags &= (~RMBTRAP); Permit(); } ReplyMsg(message); break; Actually, I use a state variable to avoid avoidable work, but you get the idea. I am not sure if the Forbid() and Permit() are necessary, but it always seems prudent to use them when messing with system-global structures. If you decide on a "best" solution, please let me know! derek
jimm@mitsumi.UUCP (Jim Mackraz) (10/06/87)
::
I think the standard way to get menus to work like dPaint is as follows:
By watching MOUSEMOVE IDCMP messages, determine when the mouse pointer
is in the menu bar (you can also poll Window.MouseX/Y, but using IDCMP
is easy and much more system-polite).
When the mouse pointer is in the menu bar, clear RMBTRAP in Window.Flags.
When the mouse pointer is not in the menu bar, set RMBTRAP in Window.Flags.
About the only possibility for mis-synchronization occurs if the user
whips the mouse into the menu bar and quickly clicks the menu button.
It is probably OK to lose the button click in this situation, but if you
are doing some painting with the right button, you need to be sure
you don't paint on your menu bar.
Don't forget that if you want to personally process the right button, you
must also set MOUSEBUTTONS in your IDCMPFlags, and to hear the mouse
move, you need both MOUSEMOVE in IDCMP, and REPORTMOUSE in Window.Flags.
Using the Intuition function ReportMouse() has historically caused
problems because of bad bindings, so if it doesn't work for you, just
set the flag yourself, either protected by Forbid/Permit, or in
assembler with an atomic operation.
Hope this helps.
jimm
PS: Bryce, I already told this to Mike.
--
Jim Mackraz
Mitsumi Technology, Inc. 408/980-5422
{amiga,pyramid}!mitsumi!jimmrichard@gryphon.CTS.COM (Richard Sexton) (10/09/87)
In article <432@mitsumi.UUCP> jimm@mitsumi.UUCP (James Mackraz) writes: >:: >I think the standard way to get menus to work like dPaint is as follows: > >By watching MOUSEMOVE IDCMP messages, determine when the mouse pointer >is in the menu bar (you can also poll Window.MouseX/Y, but using IDCMP >is easy and much more system-polite). > >When the mouse pointer is in the menu bar, clear RMBTRAP in Window.Flags. >When the mouse pointer is not in the menu bar, set RMBTRAP in Window.Flags. > I do this and it works great. I need COMPLETE control over both mouse buttons but also want menus, and this seems to do the trick. Wondered what this thread was about :-) >-- > Jim Mackraz -- Richard J. Sexton INTERNET: richard@gryphon.CTS.COM UUCP: {hplabs!hp-sdd, sdcsvax, ihnp4, nosc}!crash!gryphon!richard "It's too dark to put the keys in my ignition..."