Re: [Ql-Users] WMAN queries
On 21 Jan 2011, at 10:14, Norman Dunbar wrote: > > I've written a small demo program to show the things that happen when an > application sub-window is hit in a PE program. The program has a window > containing a single application sub-window. > > The hit routine does nothing more than this: > > ahit0 movem.l d1/d3/d5-d7/a0/a4,-(a7) ; Save the workers >moveq #0,d1 ; D1.W = Application sub window number >moveq #0,d2 ; D2.W = Ink colour > ; A4 already set to Working definition >jsr wm_swapp(a2) ; Set channel id (A0) to the subwindow > >movem.l a1-a2,-(a7) ; A1 gets corrupted >lea hit,a1; Text string to print >move.w ut_mtext,a2; Print string vector >jsr (a2) ; Print the message > >lea hitter,a1 ; Hit counter location >move.w (a1),d1; Hit counter value >addq.w #1,d1 ; Increment counter >move.w d1,(a1); Save counter >move.w ut_mint,a2 ; Print integer vector >jsr (a2) ; Print it > >movem.l (a7)+,a1-a2 ; Restore > >movem.l (a7)+,d1/d3/d5-d7/a0/a4 ; Restore the workers >moveq #0,d0 ; No errors >rts > > ; Strings and things go here > > hitter dc.w 0; How many times have I been hit? > > hit dc.w hit_e-hit-2 ; Hit message >dc.b 'HIT: ' > hit_e equ * > > Now, when run I notice the following "foibles": > > 1. The hit code is called when the pointer enters the sub-window, and > each time it moves within the sub-window. > > 2. Pressing the TAB key, which activates the sub-window, the counter > increases by TWO and not one. > > 3. Pressing the F1 key also increases the count by two. > > 4. Other keys, I have not tested everything, increment the counter by one. > > There are no menus or anything in the sub-window, it is used simply as a > display area by the program, aub-window menus come in a later article! > The hit routine is called by PE in many cases. For example the manual says "If there is no keystroke, or the keystroke is not the selection keystroke for a loose menu item or an application sub-window, then, if the pointer is within a sub-window, the hit routine is called, or else the loose menu item list is searched to find a new current item". F1 causes an event and so will cause the hit routine to be called. > Another question, I only have a single sub-window. If I comment out the > call to WM_SWAPP in the hit routine, I still see my output in the > sub-window, but it is not cleared before hand. (I can live with this) > but when I was writing PE stuff using SuperBasic and EasyPTR 3, I always > had to set the channel to the sub-window (or info window or whatever) > before I could write to it. > Commenting out WM_SWAPP is not a good idea. When I tried this program, or something very like it, HIT appeared in the main window. However, accessing the application window by a selection key caused HIT to appear in the application window. Obviously, the PE redefines the window area depending on where it finds the pointer. > So, My further queries are: > > 1. Do I need to call WM_SWAPP if I only have one sub-window or can I > assume that the channel id always refers to the sub-window regardless > unless I explicitly set it to a loose item or whatever? > You have to use WM_SWAPP > 2. If I have two or more sub-windows, does the channel id, by default, > point at the first - I haven't tested this yet - If I don't call WM_SWAPP? > No George ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] WMAN queries
Hi George, > The hit routine is called by PE in many cases. For example the manual says > "If there is no keystroke, or the keystroke is not the selection keystroke > for a loose menu item or an application sub-window, then, if the pointer is > within a sub-window, the hit routine is called, or else the loose menu item > list is searched to find a new current item". F1 causes an event and so will > cause the hit routine to be called. I presume this means that the F1 (or TAB) keystrokes are causing a HIT when the key is pressed and then another HIT when the event is raised? Although I'm not sure which event might be being raised for the TAB key. > Commenting out WM_SWAPP is not a good idea. When I tried this program, or > something very like it, HIT appeared in the main window. However, accessing > the application window by a selection key caused HIT to appear in the > application window. Obviously, the PE redefines the window area depending on > where it finds the pointer. Well, in my example, if the pointer is outside of the sub-window, nothing happens to call the HIT code regardless. It's only a HIT when the pointer is within the sub-window area, or I press TAB to activate the sub-window. > You have to use WM_SWAPP No problem. >> 2. If I have two or more sub-windows, does the channel id, by default, >> point at the first - I haven't tested this yet - If I don't call WM_SWAPP? > No Again, no problem. Thanks for your help, as ever. Cheers, Norman. -- Norman Dunbar Dunbar IT Consultants Ltd Registered address: Thorpe House 61 Richardshaw Lane Pudsey West Yorkshire United Kingdom LS28 7EL Company Number: 05132767 ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] WMAN queries
On 21 Jan 2011, at 12:58, Norman Dunbar wrote: >> >> Commenting out WM_SWAPP is not a good idea. When I tried this program, or >> something very like it, HIT appeared in the main window. However, accessing >> the application window by a selection key caused HIT to appear in the >> application window. Obviously, the PE redefines the window area depending on >> where it finds the pointer. > Well, in my example, if the pointer is outside of the sub-window, > nothing happens to call the HIT code regardless. It's only a HIT when > the pointer is within the sub-window area, or I press TAB to activate > the sub-window. In my window definition I set "A" to select the application window. So, pressing A when the pointer is outside the application window first sets the focus to the application window and then the hit routine is called. George ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] WMAN queries
On 21 Jan 2011, at 12:58, Norman Dunbar wrote: >> >> The hit routine is called by PE in many cases. For example the manual says >> "If there is no keystroke, or the keystroke is not the selection keystroke >> for a loose menu item or an application sub-window, then, if the pointer is >> within a sub-window, the hit routine is called, or else the loose menu item >> list is searched to find a new current item". F1 causes an event and so will >> cause the hit routine to be called. > I presume this means that the F1 (or TAB) keystrokes are causing a HIT > when the key is pressed and then another HIT when the event is raised? > Although I'm not sure which event might be being raised for the TAB key. I think you have to test at the start of the hit routine ahit0 what key was pressed. Any key at all pressed while the pointer is in the application window will cause the hit routine to be called. D2 will contain the uppercased keystroke with SPACE, ($20), converted to 1 and ENTER ($0A), converted to 2. So, if you wanted pressing "M" to do add to the count of hits you should check that D2.L = $4D. So the fact that F1 causes an event is really a red herring in this case. George ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] WMAN queries
Hi George, On 22/01/11 10:22, gdgqler wrote: > I think you have to test at the start of the hit routine ahit0 what key was > pressed. Any key at all pressed while the pointer is in the application > window will cause the hit routine to be called. D2 will contain the > uppercased keystroke with SPACE, ($20), converted to 1 and ENTER ($0A), > converted to 2. So, if you wanted pressing "M" to do add to the count of hits > you should check that D2.L = $4D. I'm not bothered by which key causes the counter to go up by one - it's a simple demo to show an application sub-window in action. I just found it odd that certain things causes a HIT while others seemed to cause two. I may, if I can be bothered, adapt the code to dump the registers on the first and second hit and print them out to screen on the subsequent ones - just to see the contents of the registers on entry to the "mysterious" hits. On the other hand, I may not! ;-) Cheers, Norman. -- Norman Dunbar Dunbar IT Consultants Ltd Registered address: Thorpe House 61 Richardshaw Lane Pudsey West Yorkshire United Kingdom LS28 7EL Company Number: 05132767 ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] WMAN queries
On 22 Jan 2011, at 15:44, Norman Dunbar wrote: > > On 22/01/11 10:22, gdgqler wrote: >> I think you have to test at the start of the hit routine ahit0 what key was >> pressed. Any key at all pressed while the pointer is in the application >> window will cause the hit routine to be called. D2 will contain the >> uppercased keystroke with SPACE, ($20), converted to 1 and ENTER ($0A), >> converted to 2. So, if you wanted pressing "M" to do add to the count of >> hits you should check that D2.L = $4D. > I'm not bothered by which key causes the counter to go up by one - it's > a simple demo to show an application sub-window in action. I just found > it odd that certain things causes a HIT while others seemed to cause two. > > I may, if I can be bothered, adapt the code to dump the registers on the > first and second hit and print them out to screen on the subsequent ones > - just to see the contents of the registers on entry to the "mysterious" > hits. On the other hand, I may not! ;-) > I simply use QMON. Putting a break point at ahit0 allows you to see all the registers on entry to the routine without altering the program. George ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] WMAN queries
Hi George, > 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". :-) Thanks for your help/input. Cheers, Norman. -- Norman Dunbar Dunbar IT Consultants Ltd Registered address: Thorpe House 61 Richardshaw Lane Pudsey West Yorkshire United Kingdom LS28 7EL Company Number: 05132767 ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] WMAN queries
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
Re: [Ql-Users] WMAN queries
Hi George, > 1. The expected use of the hit routine is to call WM_MHIT by JMP WM_MHIT(A2). Yes, I read that - I don't understand why, if this is the case, I can have a hit routine that is expected to jump back into the WMAN code to handle it internally. Why not just call WM_MHIT internally anyway? > 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. Yes, My original posting showed a test hit routine that I am using. It shows exactly how many times the hit routine is called for an application sub-window! Just moving the pointer over the window causes a lot of hits! Still, I'm learning new stuff! I suppose that a PE application could be written in such a way as to use a SCR_ channel for normal program output (my HIT counter for example) rather than using a dedicated sub-window, however, I'm not sure what would happen if I did so, and then moved it around the screen! I have a funny feeling I'd end up still writing to the previous location! Maybe an information window would be a better idea. Worth investigating I suspect. Cheers, Norman. -- Norman Dunbar Dunbar IT Consultants Ltd Registered address: Thorpe House 61 Richardshaw Lane Pudsey West Yorkshire United Kingdom LS28 7EL Company Number: 05132767 ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] WMAN queries
On 24 Jan 2011, at 16:52, Norman Dunbar wrote: >> >> 1. The expected use of the hit routine is to call WM_MHIT by JMP WM_MHIT(A2). > Yes, I read that - I don't understand why, if this is the case, I can > have a hit routine that is expected to jump back into the WMAN code to > handle it internally. Why not just call WM_MHIT internally anyway? > The definition of each application window has a pointer to its hit routine. Users can use that either to call WM_MHIT directly or to do something else. This is more flexible than simply having WM_MHIT called internally. >> 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. > Yes, My original posting showed a test hit routine that I am using. It > shows exactly how many times the hit routine is called for an > application sub-window! Just moving the pointer over the window causes a > lot of hits! > > Still, I'm learning new stuff! > > I suppose that a PE application could be written in such a way as to use > a SCR_ channel for normal program output (my HIT counter for example) > rather than using a dedicated sub-window, however, I'm not sure what > would happen if I did so, and then moved it around the screen! > I would not advise this! You may not be able to set this new window outside the limits already set by the PE software. That is, however you define the SCR window, it may appear inside the current PE limits of your program. > I have a funny feeling I'd end up still writing to the previous location! > > Maybe an information window would be a better idea. Worth investigating > I suspect. > I am sure that information windows are a better bet. However, with an application window you have the possibility of having a different pointer for your window. That would be more difficult for an information window. I think I almost always use information windows for displaying - - - er - - information. George ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] WMAN queries
Evening George, > The definition of each application window has a pointer to its hit routine. > Users can use that either to call WM_MHIT directly or to do something else. > This is more flexible than simply having WM_MHIT called internally. Yes, I understand that (now). Thanks. >> I suppose that a PE application could be written in such a way as to use >> a SCR_ channel for normal program output (my HIT counter for example) >> rather than using a dedicated sub-window, however, I'm not sure what >> would happen if I did so, and then moved it around the screen! > I would not advise this! You may not be able to set this new window outside > the limits already set by the PE software. That is, however you define the > SCR window, it may appear inside the current PE limits of your program. Probably best I don't attempt this then, especially as I'd have to figure out a way of opening the SCR_ channel to a location on the screen that is in absolute positioning while my application will most likely be drawn at the current pointer position. How to marry the two! >> Maybe an information window would be a better idea. Worth investigating >> I suspect. > I am sure that information windows are a better bet. However, with an > application window you have the possibility of having a different pointer for > your window. That would be more difficult for an information window. I think > I almost always use information windows for displaying - - - er - - > information. Well, I know I can print easily to an information window, I've done it for years (or was that years ago?) in Easymenu developed programs in SuperBasic. As long as I remembered to set the channel to the information window before printing! I think the use of an application sub-window for program output is acceptable and do-able, just the fact that the code in the hit routine gets called so frequently means that the code is going to have to be extremely efficient and not do any processing it doesn't have to. I feel a lot more experimenting coming on! Cheers, Norman. -- Norman Dunbar Dunbar IT Consultants Ltd Registered address: Thorpe House 61 Richardshaw Lane Pudsey West Yorkshire United Kingdom LS28 7EL Company Number: 05132767 ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
