Many thanks, Duncan, this is indeed the info I needed. The subject will quieten down now (partly because I'm away for aweek!!!)
-- Dilwyn Jones [EMAIL PROTECTED] http://www.soft.net.uk/dj/index.html -----Original Message----- From: Duncan Neithercut <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] <[EMAIL PROTECTED]> Date: 13 January 2002 19:23 Subject: RE: [ql-users] Patching SMSQ Mouse routines >Hi > >The pointer record is attached to the channel #0 driver. >It can be found by : >chbas=PEEK_L(svbas+120) : REM svbas is start of system variables >Channel0driver=PEEK_L(PEEK_l(chbas)+4) >and if >addr=Channel0driver >then >pointermove=PEEK_L(addr+126): REMark read x+y positions >ptrkey=PEEK(addr+49)+PEEK(addr+50) : REM read any mouse key pressed > >These bad bodges have worked for me across SMSQ/E 2.76 to 2.99 and from a >black box JS QL with Extended Environment to Aurora with SMSQ/E or Minerva >and finally to the Q40 suggesting that the addresses are fundamental. >The info for the addresses came from the QPTR manual - not an easy read - >and are used for my screen save controller program. I have used these bad >peeks because otherwise to legally read the pointer requires an outlined >window which becomes locked when it is covered by another window. Therefore >they are necessary for a screen saver module contoller. I assume you have >this in mind. > > Duncan > >-----Original Message----- >From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On >Behalf Of Dilwyn Jones >Sent: Saturday, January 12, 2002 3:52 PM >To: [EMAIL PROTECTED] >Subject: Re: [ql-users] Patching SMSQ Mouse routines > > >Richard Zidlicky wrote: >>> Is there a way to directly read the pointer position [take the >example >>> of a screen saver program which is displaying a screen saver module >>> (external program) but needs to monitor the mouse to see if it's >been >>> moved in order to to restore the screen] which is compatible >across >>> all or most platforms. Reading the QIMI registers will obviously >only >>> work in QIMI systems! Cuedark and a screen saver program from >Thierry >>> seem to do this but no documentation. The Jonathan Hudson Qeyes >>> program also seems to allow a program to monitor pointer position >[to >>> position its own 'eyes] without affecting the currently active job. >> >>get it from the scr/con driver, it is at 0x20 and 0x22 offsets off >the >>base of the screen driver linkage block, the one cdb+4 should point >>to. Not quite sure now if the 0x18 has to be added or not.. try >>a few peeks. > >Can you elaborate a little on this...I tried the following routine and >got nowhere, just a continuous stream of 21845 output: > >100 REMark try to read pointer co-ordinates >110 driver_address = CHAN_L(#0,4) >120 REPeat loop >130 PRINT >PEEK_W(driver_address+HEX('20')),PEEK_W(driver_address+HEX('22')) >140 END REPeat loop > >Adding $18 as you suggested made no difference at all. > >(CHAN_L is Simon Goodwin's routines for extracting info from channel >definition block). > > > > >
