Re: [Ql-Users] Pointer test
I suppose what TT calls Window Request (see way down below) is the QL equivalent of a "'desktop' type job" in this case. Anyway, thats the sort of thing that appears to be missing here. Im glad to hear that you have managed to work around the issue in your super QDT. But Im unsure whether you have also solved the problem I mentioned initially? Hmm, Ive just checked a solitaire-type card game Im (theoretically) working on. I use drag and drop there, which involves, among other steps, creating a window, outline and all, containing the card I want to move. Amazingly, it works just as it should! I right-click on a card to pick it up, drag it to some other location and let go of the button to drop it. So I may have found a workaround after all! (One can see an illustration at my website under Games/Cabal). I'll have to investigate.. Per James Hunkins wrote: Exactly - if you are moving icons between windows, you need to take control of it all. I actually got carried away as I was dragging between desktop and separate windows, all with different jobs. All I can say is that database sharing the the QL message passing stuff works quite well. We have to do a bit more on the QL than for example Windows as we don't seem to have a separate 'desktop' type job (which is why the icons in QDT do not automatically redraw in all cases) but it still works quite well. jim On 26-Jan-09, at 3:07 PM, P Witte wrote: James Hunkins wrote: You will have had better success than me, then. But I find that unless I have exclusive rights to the screen it is easy to "loose" the sprite and mess up the operation. It is many years since I worked on this problem, so I cant remember what I tried. I suppose one could OUTLine the whole screen.. Per 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 ___ 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 ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Pointer test
Exactly - if you are moving icons between windows, you need to take control of it all. I actually got carried away as I was dragging between desktop and separate windows, all with different jobs. All I can say is that database sharing the the QL message passing stuff works quite well. We have to do a bit more on the QL than for example Windows as we don't seem to have a separate 'desktop' type job (which is why the icons in QDT do not automatically redraw in all cases) but it still works quite well. jim On 26-Jan-09, at 3:07 PM, P Witte wrote: James Hunkins wrote: You will have had better success than me, then. But I find that unless I have exclusive rights to the screen it is easy to "loose" the sprite and mess up the operation. It is many years since I worked on this problem, so I cant remember what I tried. I suppose one could OUTLine the whole screen.. Per 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 ___ 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
Re: [Ql-Users] Pointer test
James Hunkins wrote: You will have had better success than me, then. But I find that unless I have exclusive rights to the screen it is easy to "loose" the sprite and mess up the operation. It is many years since I worked on this problem, so I cant remember what I tried. I suppose one could OUTLine the whole screen.. Per 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 ___ 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
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] Pointer test
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 ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Pointer test
Hi guys, 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 : ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
