Re: [Ql-Users] Pointer test
gdgqler wrote: On 25 Jan 2009, at 13:18, P Witte wrote: Ive been fiddling with a program of mine, wondering why I cant make it work. The problem boils down to the following: The code below does exactly what it should, EXCEPT the first time it is run! To test it do the following: (You need ptrmen, the EasyPointer [EP] toolkit, loaded). Fire up a SB daughter job (the example expects at least two QL windows #0 #1.) LOAD the program, type run and then press and hold ENTER or the RMB (ie DO) to execute. The first time it runs it displays Key up although a key is actually down! You need to release the key and then depress it again to get the correct result. Subsequent execution also gives the right result. To reset it, you need to start it in a pristine SB job again (ie one that has not yet had its OUTLine set). I suspect the problem lies with the PI rather than EP. Its annoying because it prevents some fine tweaking of a user interface Im working on - and because its just plain wrong. Ive spent more time than I can afford on trying to work around the problem, to no avail. Any ideas? Per 1 DIM pv%(15) 2 x% = -1: y% = -1 3 mv% = 1 + 2 + 4 4 : 5 OUTL#0 6 CLS 7 RDPT#0; 48, x%, y% 8 : 9 PRINT; 'HIT or DO. ESC to quit' 10 : 11 REPeat loop 12 RDPT#0; mv%, x%, y%: PVAL#0; pv% 13 AT 2,0 14 IF pv%(7) 4: PRINT 'key up',: ELSE : PRINT 'key down', 15 IF pv%(6) = 27: EXIT loop 16 END REPeat loop 17 : ___ This looks like the trouble I had with the resizing by outline program. When the second program starts, although I am holding down the mouse button, the PE software does not acknowledge this. I had to test first for a mouse button being down. Once the PE software accepts this then I can test for button up. George Exactly! So much for drag'n drop on the QL. Bummer ;o( Another pity is that the so called Window Request (bit #7 set in termination vector) only allows a limited number of pointer sprites to be used (move, resize and empty window). It would have been nice to be able to use any sprite, thus allowing, for example, a sprite (representing some object) to be dragged from one window and dropped on another. When I retire in about 2025 I'll take a look at these issues ;o) Per ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] test
Hi Geoff, One thing is certain and that is that I am a liar Which is very similar to my all time favourite : Everything I say is a lie. Cheers, Norman. ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] QUANTA Magazine
Evening Geoff, PS Please forgive the levity of the email, but today is a very special day. As a sign of respect to our two Scottish QL Today writers I had a rather large wee dram with my haggis, tatties and neeps. Now, who could they be I wonder? Cheers, Norman. PS. Full of finest Scotch beef and kidney! ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Pointer test
I do custom sprites for copy and moving with QDT, using the different pointer routines. Maybe not usable from within an existing call but doable. jim On 25-Jan-09, at 1:14 PM, P Witte wrote: gdgqler wrote: On 25 Jan 2009, at 13:18, P Witte wrote: Ive been fiddling with a program of mine, wondering why I cant make it work. The problem boils down to the following: The code below does exactly what it should, EXCEPT the first time it is run! To test it do the following: (You need ptrmen, the EasyPointer [EP] toolkit, loaded). Fire up a SB daughter job (the example expects at least two QL windows #0 #1.) LOAD the program, type run and then press and hold ENTER or the RMB (ie DO) to execute. The first time it runs it displays Key up although a key is actually down! You need to release the key and then depress it again to get the correct result. Subsequent execution also gives the right result. To reset it, you need to start it in a pristine SB job again (ie one that has not yet had its OUTLine set). I suspect the problem lies with the PI rather than EP. Its annoying because it prevents some fine tweaking of a user interface Im working on - and because its just plain wrong. Ive spent more time than I can afford on trying to work around the problem, to no avail. Any ideas? Per 1 DIM pv%(15) 2 x% = -1: y% = -1 3 mv% = 1 + 2 + 4 4 : 5 OUTL#0 6 CLS 7 RDPT#0; 48, x%, y% 8 : 9 PRINT; 'HIT or DO. ESC to quit' 10 : 11 REPeat loop 12 RDPT#0; mv%, x%, y%: PVAL#0; pv% 13 AT 2,0 14 IF pv%(7) 4: PRINT 'key up',: ELSE : PRINT 'key down', 15 IF pv%(6) = 27: EXIT loop 16 END REPeat loop 17 : ___ This looks like the trouble I had with the resizing by outline program. When the second program starts, although I am holding down the mouse button, the PE software does not acknowledge this. I had to test first for a mouse button being down. Once the PE software accepts this then I can test for button up. George Exactly! So much for drag'n drop on the QL. Bummer ;o( Another pity is that the so called Window Request (bit #7 set in termination vector) only allows a limited number of pointer sprites to be used (move, resize and empty window). It would have been nice to be able to use any sprite, thus allowing, for example, a sprite (representing some object) to be dragged from one window and dropped on another. When I retire in about 2025 I'll take a look at these issues ;o) Per ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
