romwa@gpu.utcs.toronto.edu (Mark Dornfeld) (11/20/88)
When using the GEM event manager, is there a way of setting up an event which involves clicking one OR two buttons? I am thinking of a case like the desktop, where one can select a disk by clicking once and get a directory by double-clicking. In reading the Laser C documentation for evnt_button, and evnt_multi it seemed as if one was restricted to only one type of button event at a time. Is a way of getting around this by polling the number of 'one-click' events? Also, when using the resource construction program from Megamax, is it possible to create an icon which is not on the main rectangle i.e. what do you do if you wish to place an icon on the background desktop? advTHANKSance NOTE: if replying via e-mail pls use the address below as I am borrowing someone's account to post this. Thanks. Pavneet Arora ...!utgpu!rom!pavneet Royal Ontario Museum 100 Queen's Park Toronto, Ontario M5S 2C6 (416) 585-5626
uace0@uhnix2.uh.edu (Michael B. Vederman) (11/20/88)
In article <1988Nov19.180454.563@gpu.utcs.toronto.edu> romwa@gpu.utcs.toronto.edu (Mark Dornfeld) writes: > >When using the GEM event manager, is there a way of setting up >an event which involves clicking one OR two buttons? I >am thinking of a case like the desktop, where one can select a >disk by clicking once and get a directory by double-clicking. If you refer to the documentation on evnt_button, you will note that the first argument is ev_bclicks, which is 'the number of times the application is waiting for the mouse button to enter a particular state (ev_bstate) within a preset time.' This argument should be 1 or 2, depending on how many clicks you wanna wait for. The return value ev_breturn is 'the number of times the button actually entered the desired state within the preset time. This number is never less than 1 or greater than the number contained in ev_bclicks.' So, ev_breturn is either 1 (single click) or 2 (double click). For evnt_multi, the number of button clicks is returned in the last argument, ev_mbreturn. - mike -- for (;;) : Use ATARINET, send an interactive do_it(c_programmers); : message such as: : Tell UH-INFO at UHUPVM1 ATARINET HELP University Atari Computer Enthusiasts : University of Houston UACE
soohoo@cory.Berkeley.EDU (Ken Soohoo) (11/21/88)
In article <1988Nov19.180454.563@gpu.utcs.toronto.edu> romwa@gpu.utcs.toronto.edu (Mark Dornfeld) writes: > >When using the GEM event manager, is there a way of setting up >an event which involves clicking one OR two buttons? I >am thinking of a case like the desktop, where one can select a >disk by clicking once and get a directory by double-clicking. > > >Pavneet Arora >...!utgpu!rom!pavneet 1) If you want to wait for a double click, the second parameter in evnt_multi() controls the # of clicks you wait for, likewise the first parameter in evnt_button(). 2) If you want to sense two click on _different_ buttons, you're going to have to go to a little work: The problem is that the evnt_multi() evnt_button() routines just don't return anything other than the left button being clicked (although you _can_ properly sense a right click with graf_mkstate() and vq_mouse(), and I'd use graf_mkstate() with other 'desktop' routines like evnt_ calls). But you really want that right button click? Install your own 68000 Assembly routine as the button event handler, it's _not_ hard! The button value comes in d0, save it out to a nice place, and then change it to a left click no matter what, and install the routine using vex_butv(); vex_butv(handle, new_function, old_function); int handle; void (*new_function), (*old_function); globl _NEW_BUT,_BUT_ADDR,_BUT_STATE * The true button state is saved and the Left button * flag is passed back to the AES mouse button interrupt routine. * * in: * _BUT_ADDR contains the address of the AES interrupt routine * that deals with mouse buttons. * * out: * _BUT_STATE contains the actual mouse button state prior to testing * to be read by the calling program. _NEW_BUT: tst d0 beq place move.w d0,_BUT_STATE move.w #1,d0 ; always return left button place: move.l _BUT_ADDR,-(sp) rts ; jmp to AES subroutine _BUT_ADDR: ds.l 1 _BUT_STATE: ds.w 1 In the above case, vex_butv(handle, NEW_BUT, &BUT_ADDR); to get into the new routine, and vex_butv(handle, BUT_ADDR, &dummy); to get out. Notable useful additions: another location to sense if the button was an "up" or a "down". --Kenneth Soohoo (soohoo@cory.Berkeley.Edu) Atari 400/800/600xl/800xl/1200/130xe/65xe, 1040ST hacker Sometime Berkeley Student, othertimes... My opinions are my OWN, not necessarily Atari's
uace0@uhnix2.uh.edu (Michael B. Vederman) (11/22/88)
In article <7632@pasteur.Berkeley.EDU> soohoo@cory.Berkeley.EDU.UUCP (Ken Soohoo) writes: >In article <1988Nov19.180454.563@gpu.utcs.toronto.edu> romwa@gpu.utcs.toronto.edu (Mark Dornfeld) writes: >> >>When using the GEM event manager, is there a way of setting up >>an event which involves clicking one OR two buttons? I >>am thinking of a case like the desktop, where one can select a >>disk by clicking once and get a directory by double-clicking. >> >> >>Pavneet Arora >>...!utgpu!rom!pavneet > >2) If you want to sense two click on _different_ buttons, you're going >to have to go to a little work: > > The problem is that the evnt_multi() evnt_button() routines > just don't return anything other than the left button being > clicked (although you _can_ properly sense a right click with > graf_mkstate() and vq_mouse(), and I'd use graf_mkstate() with > other 'desktop' routines like evnt_ calls). > >--Kenneth Soohoo (soohoo@cory.Berkeley.Edu) > Atari 400/800/600xl/800xl/1200/130xe/65xe, 1040ST hacker > Sometime Berkeley Student, othertimes... > My opinions are my OWN, not necessarily Atari's Dear Kenneth, That is not entirely true: evnt_multi and evnt_button can be used to properly detect a right button event, you cannot however wait for both a right and a left button event at the same time (seems silly but thats the way it works). If you use graf_mkstate, you will observe two things: 1) It is SLOOOOWW in returning the mouse state, and 2) It will buffer up waiting for a key event, in other words, if you call graf_mkstate 3 times, you will lose the next three key strokes! We use a modified handler for using the right and left mouse button interaction by using vq_mouse, but this too has its problems. We will shortly change all vq_mouse calls to direct memory peeks using line-a offsets. But using the vq_mouse call wouldcause the problem of the button click being cached and the next time an evnt_multi (MU_BUTTON) or evnt_button is called, that button click will be captured. In other words, sampling the mouse state using vq_mouse (and getting bstate == 1) will cause a left button event to occur for the next evnt_button call! To get around this awkwardness, do something like: do { vq_mouse(handle, &bstate, &x, &y); if (bstate & 1) evnt_button(left mouse stuff); if (bstate & 2) evnt_button(right mouse stuff); } while (bstate != your exit condition); This, however, only tests for single button clicks. Double button clicks is much more extensive if it is for both buttons to be sampled. - mike -- for (;;) : Use ATARINET, send an interactive do_it(c_programmers); : message such as: : Tell UH-INFO at UHUPVM1 ATARINET HELP University Atari Computer Enthusiasts : University of Houston UACE
saj@chinet.chi.il.us (Stephen Jacobs) (11/22/88)
I'd like to tag an old question onto this discussion of button sensing: some mouse sensing calls leave the machine in an unexpected state. In particular, after using a call (was it vq_mouse()?) to interrogate the mouse button state in a loop, an evnt_multi() waiting for a mouse event exits immediately, even if a fairly long time elapses between the completion of the loop and the call to evnt_multi(). Does this sound familiar to anyone? Would you care to explain the scope of this peculiarity, and suggest a remedy?
roeder@sbsvax.UUCP (Edgar Roeder) (11/23/88)
In article <7632@pasteur.Berkeley.EDU>, soohoo@cory.Berkeley.EDU (Ken Soohoo) writes: > In article <1988Nov19.180454.563@gpu.utcs.toronto.edu> romwa@gpu.utcs.toronto.edu (Mark Dornfeld) writes: > > > >When using the GEM event manager, is there a way of setting up > >an event which involves clicking one OR two buttons? I > >am thinking of a case like the desktop, where one can select a > >disk by clicking once and get a directory by double-clicking. > > > > The problem is that the evnt_multi() evnt_button() routines > just don't return anything other than the left button being > clicked (although you _can_ properly sense a right click with > graf_mkstate() and vq_mouse(), and I'd use graf_mkstate() with > other 'desktop' routines like evnt_ calls). > I have used another aproach to get either a left or a right button event in GEM-programs (e.g. POPLIB). I have a main loop with evnt_multi() which deals with the other events i need (keyboard, rectangle, ...). But instead of a button event i have installed a timer event (1/70 second). When i get a timer event, i check the mouse buttons via vq_mouse(). When a mouse button is pressed, the program calls an evnt_button() with the appropriate flags to recognize this as an event. The call returns immediately and then the program can handle the button event. If you don't call the evnt_button() routine, you won't be able to wait for the button released (for example to prevent the last event to be recognized twice). The 1/70 second rate is fast enough that the user does not recognize the difference between this procedure and a normal button event. And beside the mouse check you can also do other periodically needed things here (mouse echo like rubberbanding, ...). hope this helps Edgar
poole@forty2.UUCP (Simon Poole) (11/27/88)
In article <6982@chinet.chi.il.us> saj@chinet.chi.il.us (Stephen Jacobs) writes: >I'd like to tag an old question onto this discussion of button sensing: some >mouse sensing calls leave the machine in an unexpected state. In particular, >after using a call (was it vq_mouse()?) to interrogate the mouse button state >in a loop, an evnt_multi() waiting for a mouse event exits immediately, even >if a fairly long time elapses between the completion of the loop and the call >to evnt_multi(). Does this sound familiar to anyone? Would you care to >explain the scope of this peculiarity, and suggest a remedy? What's unexpected about this? Doing a vq_mouse (a VDI call) does not effect the AES event queue in anyway, in particular it doesn't cause events to get lost. In general it's not a good idea to mix AES/VDI/... calls, things can become dreadfully unsynchronized (this is one thing to look out for, if you use the solution that was suggested to the original question (installing a mouse interrupt handler that maps all buttons to the left one (something I did for UniTerm a long time ago))). -- ---------------------------------------------------------------------------- UUCP: ...mcvax!cernvax!forty2!poole Simon Poole BITNET: K538915@CZHRZU1A ----------------------------------------------------------------------------
saj@chinet.chi.il.us (Stephen Jacobs) (12/01/88)
In article <528@forty2.UUCP>, poole@forty2.UUCP (Simon Poole) writes: > In article <6982@chinet.chi.il.us> saj@chinet.chi.il.us (Stephen Jacobs) writes: > >I'd like to tag an old question onto this discussion of button sensing: some > >mouse sensing calls leave the machine in an unexpected state. In particular, > >after using a call (was it vq_mouse()?) to interrogate the mouse button state > >in a loop, an evnt_multi() waiting for a mouse event exits immediately, even > >if a fairly long time elapses between the completion of the loop and the call > >to evnt_multi(). Does this sound familiar to anyone? Would you care to > >explain the scope of this peculiarity, and suggest a remedy? > > What's unexpected about this? Doing a vq_mouse (a VDI call) does not > effect the AES event queue in anyway, in particular it doesn't cause > events to get lost. In general it's not a good idea to mix AES/VDI/... One thing that's unexpected is that my understanding of the GEM messaging philosophy is that if no program is waiting for a message, it will vanish invisibly. It would certainly annoy me if keyboard events I had no interest in and was not waiting for corrupted the message system, or if someone's mistaken attempts to use the mouse (in a program segment which used keyboard entries only) resulted in trouble in a later program segment which did use the mouse. I presume your explanation (that mouse events are queued even if they aren't being waited for) is correct, since you have much more experience than I have. I guess clearing an event queue isn't much different from clearing a type-ahead buffer, so I'll try it. Thanks. Steve