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
