Re: [Ql-Users] IOP_RPTR event vector - where is it documented.
On 26 Feb 2008, at 08:02, [EMAIL PROTECTED] wrote: In the next issue of QL Today I'm starting on the Pointer Environment. To this end, I've started simple but I find that easier! In the second article - which I'm writing right now - I've built a small 'pointer record' decoder but I'm looking for information of what exactly is set in the event vector at the end of each call to IOP_RPTR. My experimentations have shown that : After the start of the program, the pointer remains inside the hit area, a click with the mouse buttons sets the vector to $2B. This is the value when SPACE or ENTER are pressed. If the pointer remains inside the windows as above, any other keypress sets it to $2D. If the pointer has been outside of the window and comes back in, SPACE, ENTER, HIT or DO buttons set it once to $3B. Other key presses set it once to $3D. Subsequent button or key presses revert to $2B and $2D as before. If the job is 'picked' the KeyStroke is set to $08 and the event vector is set to $3D - which could be 'pointer out of window' I have the QPTR toolkit documentation from many many years ago, but I'm finding some bits missing in detail - as I think Bruce discovered some time back with the Sub Windows and stuff. I found a posting by Bruce on the list - but he never got a reply! Any information from your PE Gurus gratefully received. The manual (called description) for TurboPTR and the source code for the extra keywords (tptr510_asm) will give information about WRPTR. All this is on he SQLUG site. The information is sufficient to enable actual programming but there is far too much too put in this email! George ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] IOP_RPTR event vector - where is it documented.
Hi George, The manual (called description) for TurboPTR and the source code for the extra keywords (tptr510_asm) will give information about WRPTR. All this is on he SQLUG site. The information is sufficient to enable actual programming but there is far too much too put in this email! Ok, I'll give that a try when I have a moment of five to spare. I've had some good information from Wolfgang and Per as well. Thanks. Cheers, Norman. ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] IOP_RPTR event vector - where is it documented.
Hi Wolfgang, Use the send_event keyword. (send_event job_id,events) Thanks, I googled for something else and found a reference to the send event trap. Will have a look later. If I PICK the job, or button frame it, then DO it's button, I get the same event both times - $2D with a Key Stroke of $08. Which would be a wake. Thought it might me, I'm sure a Wake is a keypress of $08. Need much more reading though. Both showing that the pointer moved event took place, but the pointer coordinates never changed... I haven't checked that, either. I think I may have the answer. Apparently (it is written) that the coordinates in D1 when IOP_RPTR is called are only used to check where the pointer is, and if it isn't at whatever D1 says, then it is assumed to have moved. Good explanation, but if I always set it to 0,0 and I leave the pointer at 0,0 then it still 'moves'. H. FYI, this is the code I'm currently playing with : OK, thanks, I'll give it a spin this weekend. Don't expect anything grand and spectacular - this is only about my second PE assembly language program ever - apart from some 'fun' stuff I did for Dilwyn many years ago (1992 I think!) which I never really understood anyway! Cheers, Norman. ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
[Ql-Users] IOP_RPTR event vector - where is it documented.
In the next issue of QL Today I'm starting on the Pointer Environment. To this end, I've started simple but I find that easier! In the second article - which I'm writing right now - I've built a small 'pointer record' decoder but I'm looking for information of what exactly is set in the event vector at the end of each call to IOP_RPTR. My experimentations have shown that : After the start of the program, the pointer remains inside the hit area, a click with the mouse buttons sets the vector to $2B. This is the value when SPACE or ENTER are pressed. If the pointer remains inside the windows as above, any other keypress sets it to $2D. If the pointer has been outside of the window and comes back in, SPACE, ENTER, HIT or DO buttons set it once to $3B. Other key presses set it once to $3D. Subsequent button or key presses revert to $2B and $2D as before. If the job is 'picked' the KeyStroke is set to $08 and the event vector is set to $3D - which could be 'pointer out of window' I have the QPTR toolkit documentation from many many years ago, but I'm finding some bits missing in detail - as I think Bruce discovered some time back with the Sub Windows and stuff. I found a posting by Bruce on the list - but he never got a reply! Any information from your PE Gurus gratefully received. Cheers, Norman. ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] IOP_RPTR event vector - where is it documented.
On 26 Feb 2008 at 9:02, [EMAIL PROTECTED] wrote: In the next issue of QL Today I'm starting on the Pointer Environment. To this end, I've started simple but I find that easier! In the second article - which I'm writing right now - I've built a small 'pointer record' decoder but I'm looking for information of what exactly is set in the event vector at the end of each call to IOP_RPTR. Hi Norman, The event vector is described pretty well at around p.13 of the QPTR manual (just before the what you get section).. There are 4 levels to it, Pointer, Subwindow, Window and Job, each corresponding to a byte in the event vector long word. The documentation for IOP_RPTR.says that upon return of the call, all bytes are set to 0, except the LSB (the Pointer level). However, when that was drafted (at least the copy I have), the job event byte (sending events to jobs) didn't exist yet, I presume it is NOT zero'd on exit, but am not sure. The bits in the pointer byte correspond to the following: pt..kyst equ0 keystroke in window event bit pt..kypr equ1 keypress in window event bit pt..kyup equ2 key up in window event bit pt..move equ3 pointer move event bit pt..outw equ4 pointer out of window bit pt..inwn equ5 pointer in window bit pt..ofsc equ6 pointer off screen bit Each bit is set if the event took place. Hence, for example, your $2B (=00101011 binary) means that there was a keystroke in the window and a keypress, the pointer moved and was inside the window. Hope this helps. I haven't seen Bruce's email, or at least I don't remember it. What did he ask? Wolfgang ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] IOP_RPTR event vector - where is it documented.
Hi Norman,
Well my experiments, granted very simple, show the LSB ony is non-zero the
remainder are zero. Mind you, how exactly do I send an event to a job?
Use the send_event keyword. (send_event job_id,events)
If I PICK the job, or button frame it, then DO it's button, I get the same
event both times - $2D with a Key Stroke of $08.
Which would be a wake.
SNIP bitmap details
Interesting. If I position the pointer exactly on 0,0 and simply press a
key (including space and enter) I still get the pointer moved bit set.
Strange
I tried repeatedly pressing the same key when the pointer was stationary
- I always get 'the pointer moved', as follows :
xorg yorg eventvec ks kd
002B 01 01 - Pressing SPACE key without moving pointer
002B 02 02 - Pressing ENTER key without moving pointer
002D 66 00 - Pressing 'f' key without moving pointer.
And so on.
So my $2B (0010 1011) is as above, Keystroke in window +
keypress in window + Pointer moved + Pointer in window.
And my $2D (0010 1101) is Keystroke in window + Key up in Window +
Pointer moved + Pointer in window.
Yeah, well, you'll probably get key down up randomly depending on
whether, when you get out of the read loop,
a key was pressed still or not.
Both showing that the pointer moved event took place, but the pointer
coordinates never changed. In addition, in my call to IOP_RPTR, I set the
initial coordinates to 0,0 each time around the loop - it never affects
the pointer position - as far as I can see that is! However, I'm willing
to be convinced that internally it is setting them to 0,0 and then
resetting them to the current pointer position - but I honestly don't
know.
I haven't checked that, either.
(...)
FYI, this is the code I'm currently playing with :
(...)
OK, thanks, I'll give it a spin this weekend.
Wolfgang
___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] IOP_RPTR event vector - where is it documented.
[EMAIL PROTECTED] writes: However, when that was drafted (at least the copy I have), the job event byte (sending events to jobs) didn't exist yet, I presume it is NOT zero'd on exit, but am not sure. Well my experiments, granted very simple, show the LSB ony is non-zero the remainder are zero. Mind you, how exactly do I send an event to a job? If I PICK the job, or button frame it, then DO it's button, I get the same event both times - $2D with a Key Stroke of $08. These are a different kind of event. You need to use a trap (sms.sevt)to send a job event. Used for jobs communication. Eg job A, a game say, is at the top of its program loop waiting for either user input or a job event (using mcallt in EP). Another job, job B, running an independent timer asynchronously, sends a pre-arranged event to job A signifying Time's up!. This triggers job A's call and drops into the program's time-out handling code. The above it what I do in D-Miner. The Timer toolkit (source code included on www.witteware.com/knoware toolkits/Timer) demonstrates a use of job events. Per ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
