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
