Re: [Ql-Users] MCALLT
The long word containing the hit position has pos in its top word and len in its bottom word. I hope that this will be of some help! George Thanks. I was hoping that someone could explain the one specific issue, namely that while the pointer is in an application window with no menu and with pan/scroll bars, a different value is returned when keyboard is used than when the mouse is used. It's probably as simple as upper word returns a key code (which doesn't have to be an event code at all), while mouse returns 0 in the upper word. I'd just never noticed this before and it's easy to deal with by masking out the upper word. I assume that there is a menu in the application window (since there are scroll bars) but that the pointer is not on any of the items. If so what keypress is used and what mouse click would be used instead? If the application window is set up with a select key, A, say. Then pressing A will set the pointer to the application window. Pressing A again will set the pointer to the scroll bar. Further presses of A will cause the pointer to switch successively between window and scroll bars. This gives exactly the same result as just moving the mouse to these spots. Presumably then this is not the keypress mentioned. Of course, pressing SPACE or ENTER is equivalent to a left or right click of a mouse. Is this what causes a different result? Anyway how do you have an application window with no items but with scroll bars? Obviously I have misunderstood the problem! George ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] MCALLT
The long word containing the hit position has pos in its top word and len in its bottom word. I hope that this will be of some help! George Thanks. I was hoping that someone could explain the one specific issue, namely that while the pointer is in an application window with no menu and with pan/scroll bars, a different value is returned when keyboard is used than when the mouse is used. It's probably as simple as upper word returns a key code (which doesn't have to be an event code at all), while mouse returns 0 in the upper word. I'd just never noticed this before and it's easy to deal with by masking out the upper word. I assume that there is a menu in the application window (since there are scroll bars) but that the pointer is not on any of the items. If so what keypress is used and what mouse click would be used instead? If the application window is set up with a select key, A, say. Then pressing A will set the pointer to the application window. Pressing A again will set the pointer to the scroll bar. Further presses of A will cause the pointer to switch successively between window and scroll bars. This gives exactly the same result as just moving the mouse to these spots. Presumably then this is not the keypress mentioned. Of course, pressing SPACE or ENTER is equivalent to a left or right click of a mouse. Is this what causes a different result? Anyway how do you have an application window with no items but with scroll bars? Obviously I have misunderstood the problem! I think that the difference is that the pointer is moved either by the mouse or by the arrow keys on the keyboard. This seems to produce a different return from MCALLT. George ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] MCALLT
The long word containing the hit position has pos in its top word and len in its bottom word. I hope that this will be of some help! George Thanks. I was hoping that someone could explain the one specific issue, namely that while the pointer is in an application window with no menu and with pan/scroll bars, a different value is returned when keyboard is used than when the mouse is used. It's probably as simple as upper word returns a key code (which doesn't have to be an event code at all), while mouse returns 0 in the upper word. I'd just never noticed this before and it's easy to deal with by masking out the upper word. I assume that there is a menu in the application window (since there are scroll bars) but that the pointer is not on any of the items. If so what keypress is used and what mouse click would be used instead? If the application window is set up with a select key, A, say. Then pressing A will set the pointer to the application window. Pressing A again will set the pointer to the scroll bar. Further presses of A will cause the pointer to switch successively between window and scroll bars. This gives exactly the same result as just moving the mouse to these spots. Presumably then this is not the keypress mentioned. Of course, pressing SPACE or ENTER is equivalent to a left or right click of a mouse. Is this what causes a different result? Anyway how do you have an application window with no items but with scroll bars? Obviously I have misunderstood the problem! I think that the difference is that the pointer is moved either by the mouse or by the arrow keys on the keyboard. This seems to produce a different return from MCALLT. If the pointer is inside an application window and is moved the application's hit routine (which is compulsory) is called. I have never found it necessary to do more than set WM.MHIT as this routine. This automatically does nothing unless the pointer is moved onto an item or moved away from an item in which case the item's border is set or unset. Of course if a HIT or DO occurs on an item the appropriate action routine is called by WM.MHIT. I have looked at the status area to see what happens if the pointer is moved into an application window by mouse and by arrow keys. I cannot detect any difference. George ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] MCALLT
Anyway how do you have an application window with no items but with scroll bars? Obviously I have misunderstood the problem! George The application window is used to display graphics, as a window onto a larger page size. The scroll bars are set up with the Easyptr MAWBAR command, which allows you to control the bar from the co-ordinates of the area specified - a manual bar rather than ones set up automatically by a menu, if you like. This particular issue is I'm pretty sure Easyptr-specific and ONLY occurs in application windows with NO menu.The upper word always returns the code of the key pressed (the key which caused MCALLT to return), even if that is not an action key, and is not just a cursor key, for example. As long as it's an official facility which isn't a feature of a particular Easyptr version, it can be useful in some circumstances, although it's probably only the same data as the MKEY% function returns (code of key causing last return from MCALL, RDPT or MINPUT for example). Now I know what's going on, it's easy to handle, although it might mean a little change to handle this in my older programs which don't expect a return value in the upper bytes. Anyone wanting to embarrass me can try any of my older programs which manipulate text or graphics in an application window without menu - move the pointer into the window with the mouse, then use the cursor keys to move the pointer within the window and tell me which programs fall over at that point! Dilwyn Jones ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] MCALLT
On 9 Sep 2009, at 14:31, Dilwyn Jones wrote: I wonder if anyone can help me with a feature of the Easyptr 4 MCALLT function I stumbled across when trying to write a little program using an application window with no menu and a simple MAWBAR installed. It all works well enough using the mouse, but if I press a key in the keyboard, e.g. a cursor arrow key, I get a different result. The menu has one loose item (ESC, loose item -1) and just a single application window number 1. Any example menu should work as long as the application window is less than 200x200 10 MDRAW #0,win1_qform_testmenu_men 15 MAWBAR #0,1,200,200 20 REPeat program 30 time% = 250 : event% = 255 : ch% = 0 40 num = MCALLT(#ch%,event%,time%) 50 SELect ON num 60 =-1 : EXIT program : REMark Esc loose item 70 =REMAINDER 80 MWINDOW #0,1 : CLS #0 : INK #0,0 : OVER #0,0 : PRINT #0,num,HEX$(num,32) 90 END SELect 100 END REPeat program 110 MCLEAR #0 The MAWBAR in line 15 just sets up pan and scroll bars for an area (size not significant as long as larger than the application window, otherwise pan and scroll bars not needed of course) Line 30 time% makes MCALLT time out after 5 seconds (time, for bubble help, not used here) event% just makes sure it returns after all window events (sleep, etc, again not significant here) Line 80 just shows the value returned by MCALLT into 'num' and shows it in decimal and in hex to make it easier to look at what's happening. If you move the mouse inside the application window, it retruns 0001 as you'd expect (application window number). If, however, you move the pointer using the cursor arrow keys on the keyboard while the pointer is inside the application window instead it returns $00C1 etc, with the upper 4 hex digits containing the ASCII code of the key pressed (any key, not just cursor keys) not just the app window number as you'd get using the mouse. It looks like there is an undocumented facility where MCALLT (not checked MCALL) can tell you if the mouse or keyboard did the last operationin in an app window with no menu and scroll bars??? Maybe I misunderstand the feature??? Can anyone else confirm this before I pester Marcel about it, I think I'm already on his blacklist about Easyptr before I make things even worse :o) I can't say what MCALLT will do but it will be, no doubt much the same as WRPTRT in TurboPTR. This function reads the pointer, with timeout, and returns appropriate information. This can be quite complicated and some of it, relating to pan and scroll bars, does not seem to be in Jochen's QPTR manual. The definitions of the functions WRPTR and WRPTRT are: WRPTR (wwd [,adr]) and WRPTRT(wwd, timeout, events [,adr]) Both these functions read the pointer and return with information in a long word k. wwd is the address of the working definition. WRPTR returns after a loose item or menu item in an application window has been hit. WRPTRT is the same as WRPTR but in addition it has a timeout facility (timeout). It also has the facility to specify, in events, which job events it will return on. The definition of the long word k is: Byte Byte Word pad codeItem number Bit 0 of pad is 1 for a DO and 0 for a HIT. The other bits of pad are undefined. Code is -128 to signify an error -4 to signal timeout -3 to signify pan/scroll -2 to signify an event -1 to signify a loose item the number of an application window otherwise Item number is the value of the event or pan/scroll, or the item number of the loose item or of the application window menu. For an application window, number -1 means cancel and -2 means do. Other numbers are the numbers of the menu items The value of an event is: 1 for do (ENTER) 2 for quit 4 for help 8 for move 16 for resize 32 for sleep 64 for wake For a pan/scroll the hit position on a scroll bar is placed in the location pointed to by the parameter adr. The value of a pan/scroll is: 256*j + n where n is the section of the bar to be panned/scrolled and j is as follows: Space/Hit Enter/Do Where $70$74 Top arrows $71$75 Bottom arrows $72$76 Left arrows $73$77 Right arrows $78$7C Scroll bar $7A$7E Pan bar The long word containing the hit position
Re: [Ql-Users] MCALLT
The long word containing the hit position has pos in its top word and len in its bottom word. I hope that this will be of some help! George Thanks. I was hoping that someone could explain the one specific issue, namely that while the pointer is in an application window with no menu and with pan/scroll bars, a different value is returned when keyboard is used than when the mouse is used. It's probably as simple as upper word returns a key code (which doesn't have to be an event code at all), while mouse returns 0 in the upper word. I'd just never noticed this before and it's easy to deal with by masking out the upper word. Dilwyn Jones ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] MCALLT
A quick test with one of my own programs confirms this feature. (mouse in the one apl window with a pic in it and a scroll bar.) The manual page for MCALL states that a special operation code is delivered in num if there are bars set up with MAWBAR and refers to Important_txt, MAWBAR/MAWBARR chapter. This states that this operation code is masked with the pixel position, which is zero when the mouse is not hit. It doesn't say that it is the ascii code when a key is used. When I wait for the timeout the returned code is $FB00. The high word -1 probably signals that no key is pressed, but what to make of the $FB00? Bob Could this FB00 be the -1280 or -$500 which MCALLT returns in the event of a timeout or event? Time to call in the cavalry...*Marcel* -- Dilwyn Jones ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] MCALLT
Op Wed, 09 Sep 2009 15:31:27 +0200 schreef Dilwyn Jones dil...@evans1511.fsnet.co.uk: If, however, you move the pointer using the cursor arrow keys on the keyboard while the pointer is inside the application window instead it returns $00C1 etc, with the upper 4 hex digits containing the ASCII code of the key pressed (any key, not just cursor keys) not just the app window number as you'd get using the mouse. It looks like there is an undocumented facility where MCALLT (not checked MCALL) can tell you if the mouse or keyboard did the last operationin in an app window with no menu and scroll bars??? Maybe I misunderstand the feature??? Can anyone else confirm this before I pester Marcel about it, I think I'm already on his blacklist about Easyptr before I make things even worse :o) A quick test with one of my own programs confirms this feature. (mouse in the one apl window with a pic in it and a scroll bar.) The manual page for MCALL states that a special operation code is delivered in num if there are bars set up with MAWBAR and refers to Important_txt, MAWBAR/MAWBARR chapter. This states that this operation code is masked with the pixel position, which is zero when the mouse is not hit. It doesn't say that it is the ascii code when a key is used. When I wait for the timeout the returned code is $FB00. The high word -1 probably signals that no key is pressed, but what to make of the $FB00? Bob -- Gemaakt met Opera's revolutionaire e-mailprogramma: http://www.opera.com/mail/ ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
[Ql-Users] MCALLT
I wonder if anyone can help me with a feature of the Easyptr 4 MCALLT function I stumbled across when trying to write a little program using an application window with no menu and a simple MAWBAR installed. It all works well enough using the mouse, but if I press a key in the keyboard, e.g. a cursor arrow key, I get a different result. The menu has one loose item (ESC, loose item -1) and just a single application window number 1. Any example menu should work as long as the application window is less than 200x200 10 MDRAW #0,win1_qform_testmenu_men 15 MAWBAR #0,1,200,200 20 REPeat program 30 time% = 250 : event% = 255 : ch% = 0 40 num = MCALLT(#ch%,event%,time%) 50 SELect ON num 60 =-1 : EXIT program : REMark Esc loose item 70 =REMAINDER 80 MWINDOW #0,1 : CLS #0 : INK #0,0 : OVER #0,0 : PRINT #0,num,HEX$(num,32) 90 END SELect 100 END REPeat program 110 MCLEAR #0 The MAWBAR in line 15 just sets up pan and scroll bars for an area (size not significant as long as larger than the application window, otherwise pan and scroll bars not needed of course) Line 30 time% makes MCALLT time out after 5 seconds (time, for bubble help, not used here) event% just makes sure it returns after all window events (sleep, etc, again not significant here) Line 80 just shows the value returned by MCALLT into 'num' and shows it in decimal and in hex to make it easier to look at what's happening. If you move the mouse inside the application window, it retruns 0001 as you'd expect (application window number). If, however, you move the pointer using the cursor arrow keys on the keyboard while the pointer is inside the application window instead it returns $00C1 etc, with the upper 4 hex digits containing the ASCII code of the key pressed (any key, not just cursor keys) not just the app window number as you'd get using the mouse. It looks like there is an undocumented facility where MCALLT (not checked MCALL) can tell you if the mouse or keyboard did the last operationin in an app window with no menu and scroll bars??? Maybe I misunderstand the feature??? Can anyone else confirm this before I pester Marcel about it, I think I'm already on his blacklist about Easyptr before I make things even worse :o) Dilwyn Jones ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] MCALLT
Dilwyn Jones schreef: Dilwyn Jones schreef: Does anyone have any experience of using MCALLT in Easyptr? SNIP Hi Dilwyn, You could download Per Witte's 'POP2.zip' from http://www.bixio60.org. François Van Emelen Thanks François, Bob and Marcel for your quick replies. Who's site is that, BTW? I think it's Fabrizio Diversi's. François Van Emelen I'd forgotten about Per's article :o| - I'll go back to Toady have a look at that. And thanks to Marcel for the manual text, clarifies some things quite a bit, especially the event 'nybble' being a 'byte', or 'words' to that effect ;-) ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
[ql-users] MCALLT
Does anyone have any experience of using MCALLT in Easyptr? I'm looking for a few examples of making use of the timeout and events (general tinkering), and perhaps for adding help 'bubbles' to my programs. 2 of my programs (Decimal Invaders and Status) use the timeout facility to allow something to be counted or printed if nothing happens within a short time, but that's about as far as I ever got with it. The Easyptr manual is pretty scant on the subject, basically describing it as an MCALL with a couple of extra parameters in Easyptr's IMPORTANT_TXT file. It doesn't really give any examples showing to properly use it. As far as I know, item=MCALLT(#ch%\event%,time%) times out after time% frames (50=1 second), and the event% parameter seems to be: bits0-7 set - allow termination of call by events listed in pt1/42 (Do, ESC, F1 etc) as long as \ is used after #ch% bits 8-15 (although suggested to be upper nybble bits 12-15) allow smsq/e job events??? Since SMSQ/E allows 8 events but only 4 bits are available, if I'm correct it must be a hex value 0 to 7 in those 4 bits??? A timeout return seems to be indicated by item=-1280 (not sure of the significance of that number) and event% being returned unchanged in value if no 'event' occurred. Can anyone give a better explanation, or provide a few examples or documentation on the subject? Apart from the bubble help perhaps I don't really have any particular use in mind, just learnign more about it. -- Dilwyn Jones -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.405 / Virus Database: 268.11.7/436 - Release Date: 01/09/2006 ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] MCALLT
Dilwyn Jones schreef: Does anyone have any experience of using MCALLT in Easyptr? SNIP Hi Dilwyn, You could download Per Witte's 'POP2.zip' from http://www.bixio60.org. François Van Emelen ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] MCALLT
Hi Dilwyn, Does anyone have any experience of using MCALLT in Easyptr? I'm looking for a few examples of making use of the timeout and events (general tinkering), and perhaps for adding help 'bubbles' to my programs. I have suqcessfully adapted the help/hint example, as Per Witte described it in QLToday v10i3, for Suqcess 2.04. However there were some unexpected differences with MCALL. 1) The timing of the pan/scroll arrows bars was affected. The rows in the AW moved 2 or 3 lines with one click instead of one. This was solved by Marcel (who else) with the latest version of ptrmenr_cde v4.10. So make sure you use the latest version if you use scrollable AW items. 2) I also used: key=MCALL(#ch%,...): PVAL #ch%,erg% and then I checked erg%(16) for the Wake key (CF2), for which there was no Loose Item. This doesn't work with MCALLT. Marcel suggested the following: ev% = 64 key = MCALLT(#ch, ev%, 50) SELect ON key = -1280: REMark Timeout or event IF ev% = 64 THEN [...] CTRL+F2 END IF IF ev% = 0 THEN [...] Timeout END IF END SELect I gave Wake its own LI anyway. Hopefully this is of some help. Bob Spelten -- Gemaakt met Opera's revolutionaire e-mailprogramma: http://www.opera.com/mail/ ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] MCALLT
Dilwyn Jones schreef: Does anyone have any experience of using MCALLT in Easyptr? SNIP Hi Dilwyn, You could download Per Witte's 'POP2.zip' from http://www.bixio60.org. François Van Emelen Thanks François, Bob and Marcel for your quick replies. Who's site is that, BTW? I'd forgotten about Per's article :o| - I'll go back to Toady have a look at that. And thanks to Marcel for the manual text, clarifies some things quite a bit, especially the event 'nybble' being a 'byte', or 'words' to that effect ;-) -- Dilwyn Jones -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 0.0.405 / Virus Database: 268.11.7/436 - Release Date: 01/09/2006 ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
