On 24 Jan 2011, at 13:07, Norman Dunbar wrote:
>>
>> I simply use QMON. Putting a break point at ahit0...
> Very wise, that's what I did. Interesting results.
>
> Starting the program and pressing TAB to activate the application
> sub-window gives two hits. On entry to the first hit, I see the pointer
> position in D1, the keystroke in D2 as -1 (external keystroke), the
> event in D4 as 0. D6 is also 0.
>
> Giving QMON a go command, I immediately get a second hit. This time, D1
> has changed to new pointer position, D2 is 0, D4 is still zero and D6 is
> $80.
>
> So, for the TAB key, I see the pointer position changing, a mystery
> value in D6 and the keystroke conges too. Nothing else. D4 never
> indicates an event but the docs say PT__DO or PT__CANCEL only, or zero.
>
>
> Without moving the pointer, I now press F1 and get a break. This time D1
> is unchanged (as expected) D2 is zero as is D4 and D6. Giving QMON a go
> results in an immediate hit with the only change being D6 now set to $80.
>
>
> For my own curiosity, I tried a SPACE. This time I got a hit with D2 = 1
> (as expected) and D4 & D6 = 0.
>
> With an ENTER I get D2 = 2 (as expected) and D6=0 but D4 is now = $10
> for PT_DO, the event number.
>
> And finally, I tried ESC. Nothing happened. However, as I have a loose
> item with ESC as the selection key, I put a break on the afun0_0 code
> and it was catching the ESC event before the application sub-window.
>
> The pointer position was interesting. It appears to be (as documented)
> the absolute position relative to the start of the screen (0,0) and not
> the application sub-window, however, I was emulation with a window
> dimension of 1024 by 768 and was able to get a pointer position of
> 3936,658 and 3872,649 - which is interesting to say the least!
>
> So, for the double hit with the TAB key i *think* what I'm seeing is :
>
> Hit 1: External keystroke detected. Window is activated causing a hit.
> Pointer pos is where it was on screen when TAB key pressed.
>
> Hit 2: Pointer has changed position within the application sub-window
> causing another hit. Pointer "jumps" from where it was when TAB pressed
> to where it is "defaulted" to be in the window on activation.
>
> For the F1 double hit, I have no idea at all! There are no keystokes, no
> changes of pointer position and no events, as such, as the PT__HELP
> event expected by F1 is handled by WMAN and never gets to the
> application sub-window hit routine in D4.
>
> I don't intent to spend much more time on this "foible". :-)
I suspect that all these peculiar happenings occur because the application
window hit routine ahit0 allows everything.
1. The expected use of the hit routine is to call WM_MHIT by JMP WM_MHIT(A2).
2. The manual says that WM_RPTR does, among a lot of other things -
"if in application window
call hit routine
next read pointer"
A program in which ahit0 prints "HIT" on a "hit" (SPACE) and resets the
application window on a "DO" (ENTER) but ignores everything else looks normal
in execution but shows the constant reentering of ahit0 when run under QMON.
George
_______________________________________________
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm
