Wolfgang writes:
<>
> > I feared, but was hoping I wouldnt have to, go there
>
> ????
having to fiddle around to do it manually.
> > Thank you for your code ;) I think this is just what Im looking for. I
> > shall test it as soon as I can.
> OK let me know if it breaks.
>
> (...)
> > By DOing the liberated button, I want it to jump back into the BF, but
> > whatever the x-coordinate I provide, wm.prpos positions the button
wherever
> > it thinks fit. Eg, if the free button was at (0,100) wm.prpos puts it in
> > the correct place at the end of the row of buttons at the top of the
screen,
> > eg (764,0), exactly as specified. However, if the free button was at the
> > other screen edge, eg (972,50), wm.prpos puts it at (0,0)! If the free
> > button was anywhere in between, wm.prpos puts it in some intermediate
> > position (xxx,0). Surely this must be an "issue"? BTW, this behaviour is
the
> > same whether QPC is running in HiColor or QLColor mode
> ?
> This something I'm unable to reproduce.
init (open con, wm.setup etc)
wm.prpos
wm.wdraw
loop
wm.rptrt
if HIT then release BF and interactively move
elseif DO then
get coordinates from BF Thing and
wm.prpos
endif
endloop
As you see from this (partial and oversimplified) representation, I dont
wm.rset or anything like that, just re-call wm.prpos. This may not be
how wm.prpos is designed to operate..
<>> Anyway, the BF doesn't place anything anywhere, it is your code that
does so.
> The second code example I've sent you should tell you how to position your
wdw again
> where you want it.
Yes, Im aware of that, hence my need to use wm.prpos.
> Just as a recap, let me remind you how the PE positions (primary) windows.
> If you tell it to position a window at coords x,y, it puts the POINTER at
x,y.
> Then it draws the wdw around the pointer in such a way that the pointer,
being at
> coords x,y, will be located within the window at the coords x2,y2
(relative to the wdw
> origin), the coords x2,y2 being the coords given in ww_xorg in the working
definition
> (!!!!!!!).
>
> In other words, when positioning primary wdws, ww_xorg and ww_yorg contain
not the
> window position, but the initial pointer position of the pointer within
the window.
This explains why the buttons overlap initially. My WD's default pointer
position was set to (0,0), but this is inside the border.
> I'm sorry if the above sounded pedantic and only told you things you
already knew!
Its always difficult to know what others know. Its years since I last did
any serious PE programming in assembler, so Im starting again almost from
scratch. And I thought doing just a simple little button affair would allow
me to get acquainted with some of the new facilities in a controlled,
overseeable environment! Ha!
Thanks for your help. I hope to get it all sorted out this weekend.
Per
