Thanks Per. I've haven't had time to look that up in my QDOS/SMS reference manual, but I don't think iop.rptr is included. The copy I have is probably first edition. Its hard to see how OS Trap information could be copywrited or what good that does to the SMSQ cause.
Cheers Malcolm P Witte wrote: > Malcolm Lear writes: > >> Has anyone got any info on the low level mouse interface in the PE. > > I > >> assume it must be a >> documented Trap which returns both absolute pointer position and the >> relative position since >> the last call. I also need to determine the mouse button status. Any >> help would be greatly >> appreciated. I seem to remember that the info was available on the > > QXL > >> using KEYROW(24?). > > > QPTR, the pointer toolkit bible is essential for PE programming. I > hope noone will use features such as the PE linkage block Wolfgang was > asking about for published programs as it is not documented there, and > thus may be liable to change! > > Im not sure how much of the documentation ought to be reproduce here > as it probably is copywrited material. Any thoughts on that, anyone? > > The call you require is iop.rptr, trap#3, d0=$71. It is quite a > complex trap that will do all the things youre asking for (though in > its own way ;) The S*Basic equivalents, both in the Qptr toolkit > (RPTR) and various other implementations (eg EasyPTR's RDPT), are > rather oversimplyfied, unfortunately. However, they may do what you > want. If you dont have, or dont want to use, the Qptr toolkit you can > still use the trap by writing your own keyword to implement the > functionality youre interested in (Youll still want the documentation, > though). > > Ive seen somewhere that if the trap is called with bit #6 set in the > termination vector (lsb d2) it should return if the pointer is moved > to the edge of the screen, but I havent got this to work. Anyone got > an update on that? > > A minor undocumented point on iop.rptr. My notes say a0 (channel ID) > is smashed if the call fails. > > One improvement I would like to see: When making a window request > call (bit #7 set in termination vector) you currently only have a > choice of displaying one of three of the internal sprites (move, > change size, empty window). Why not allow a user defined sprite > option as well? Would be useful for other window resizing or moving > schemes. > > Per > [EMAIL PROTECTED] > > > > > > > > > >
