Path: utzoo!attcan!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!munnari.oz.au!brolga!bunyip.cc.uq.oz.au!oat!qut.edu.au!zseelunnon
From: zseelunnon@qut.edu.au
Newsgroups: comp.sys.atari.st.tech
Subject: Re: How does one relocate the Mouse ptr from pt A to B?
Message-ID: <1990Dec20.100134.21871@qut.edu.au>
Date: 20 Dec 90 15:01:34 GMT
References: <9577@ncar.ucar.edu>
Organization: Queensland University of Technology
Lines: 50

In article <9577@ncar.ucar.edu>, moses@hao.ucar.edu (Julie Moses) writes:
> Can someone explain how one can move the mouse location from one
> x,y coordinate to another 'automatically', i.e. without having to
> manually move it?
> 
> Will doing this cause any problems with the AES? Make it lose track
> of the mouse?

I beleive there are a couple of ways. The way I did it in a recent 
hack job :-) was to use the VDI mouse exchange vector system call
the curret x co-ordinate from the driver appears in d0 and y in d1
change these to your new location and vector through the address 
returned originally by vex_motd ( I think thats the call name I 
haven't got my ref manual here ). Someone has mentioned that the
mouse and kbd exchange vectors are semi priveleged (for aes use only)
but my DRI developers kit for GEM 3 makes no assertions of this 
nature ( I trust DRI when it comes to gem :-) anyway you need to 
be VERY carefull with this call. 

1. The mouse vector MUST be restored before you exit your program
otherwise when TOS releases you programs memory and zaps it the 
routine you specified in the mouse call disappears and VDI vectors
int thin air next time it execute the mouse driver, This applies 
to error and exception bomb outs too, so either your programs must 
be exception proof or you must handle exceptions yourself. (ATARI -
I think you missed this one in TOS1.4 bomb handler ) 

2.) The routine inserted should be short: the mouse handler seems to be 
called at EVERY vbl rather than when the mouse position changes 
(only drawing does not occur if the mouse has not moved) *Atari should
fix this too it is a waste of time to execute the mouse driver if no
movement was detected by the IKBD* 

There are probably some other gotchas but I can't recall them right
now, but use of the mouse exchange vector (boy will I get flamed now)
is probably ok if the above rules are followed and the handler is only 
installed while the mouse is in your space ie over your window (
a watchbox will be needed) unless of course (in apollo terms :-) you
"borrow" the screen for a bit ( Really love that term :-)

Well that is my (confused) contribution to this thread


> 
> J.Moses

		BOB
		R_Lunnon@qut.edu.au
		ZSEELUNNON@qut.edu.au
		lunnon@design.fen.qut.edu.au