moses@hao.ucar.edu (Julie Moses) (12/18/90)
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? J.Moses
rosenkra@convex.com (William Rosencranz) (12/18/90)
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? i don't know what u mean by "automatically" vs "manually". you can install a new mouse position vector with vex_motn (i don't remember the exact name but this is at least close). it is called with mouse x,y in d0/d1 and you can change it. before your handler does its rts, it can change the d0/d1 based on some application-specific action, and the new coords get passed on to the AES. from that point on, the AES updates its idea of where the mouse is based on your d0.w/d1.w values. i don't know if this can be done in C. it will be non-portable at best (using asm(...) statements). i wrote my handler in assembler and have had no problems. >Will doing this cause any problems with the AES? Make it lose track >of the mouse? there should be no problems. just make sure to restore the old handler before your application finishes... -bill rosenkra@convex.com (maybe this can go in the FAQ for this newsgroup as it has been asked just recently, that is if there is a FAQ...) -- Bill Rosenkranz |UUCP: {uunet,texsun}!convex!c1yankee!rosenkra Convex Computer Corp. |ARPA: rosenkra%c1yankee@convex.com
domen@wiener.crin.fr (Eric Domenjoud) (12/20/90)
In article <1990Dec20.100134.21871@qut.edu.au> zseelunnon@qut.edu.au writes: : : : 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 Using the vex_motv function is actually not really ok. If the mouse moves while this function is changing the vector, then the ST crashes (at least with TOS 1.0). One should prevent the mouse to move by setting the system variable which says wether the keyboard interrupts must be handled or not. Unfortunately, I can't remember the location of this variable. Eric Domenjoud e-mail: domen@loria.crin.fr
zseelunnon@qut.edu.au (12/20/90)
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
zseelunnon@qut.edu.au (12/25/90)
In article <DOMEN.90Dec20142927@wiener.crin.fr>, domen@wiener.crin.fr (Eric Domenjoud) writes: > In article <1990Dec20.100134.21871@qut.edu.au> zseelunnon@qut.edu.au writes: > > : > : > : > 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 > > Using the vex_motv function is actually not really ok. If the mouse > moves while this function is changing the vector, then the ST crashes > (at least with TOS 1.0). One should prevent the mouse to move by > setting the system variable which says wether the keyboard interrupts > must be handled or not. Unfortunately, I can't remember the location > of this variable. Hmm! didn't know that one (I have TOS1.4) and have not seen this behaviour, what exception does it cause ?. I have a pile of interrupt routines running and occasionally get a spurious-interrupt exception generated (lotsa bombs ). I would have thought that this change would have been atomic. Can you say B.U.G. ????? BTW - From memory the mouse vector is stored in a documented place in the LINE-A variable set so I spose you could be more atomic about it and do it yourself there ( At the risk of being TT incompatible I guess ) > > Eric Domenjoud > e-mail: domen@loria.crin.fr BOB R.Lunnon@qut.edu.au ZSEELUNNON@qut.edu.au lunnon@design.fen.qut.edu.au (any or all of these paths might work for you) (My last signature was wrong - oops :-)
domen@wiener.crin.fr (Eric Domenjoud) (01/04/91)
In article <1990Dec24.131906.22082@qut.edu.au> zseelunnon@qut.edu.au writes: > Hmm! didn't know that one (I have TOS1.4) and have not seen this behaviour, > what exception does it cause ?. I have a pile of interrupt routines running > and occasionally get a spurious-interrupt exception generated (lotsa bombs ). > I would have thought that this change would have been atomic. > > Can you say B.U.G. ????? > > BTW - From memory the mouse vector is stored in a documented place > in the LINE-A variable set so I spose you could be more atomic about it > and do it yourself there ( At the risk of being TT incompatible I guess ) It does not cause an exception but simply crashes the ST. The problem is due to the fact that setting the mouse vectors lasts more than one cycle and thus may be interrupted. If the mouse moves while the vector is beeing setted, the mouse handler is called and the ST crashes because the vector is not a valid one. Try to write a program that calls vex_motv 10000 times and move the mouse. With TOS 1.0, it crashes. Eric Domenjoud e-mail: domen@loria.crin.fr