In a message dated 07/01/04 07:47:56 GMT Standard Time, [EMAIL PROTECTED] writes:
In the meantime I had also found some issues with the following
routines and just made new wrappers that I use instead of those
included in the C libary. The dates are what I have on the files when
I made my own
Looking through some old notes, Marcel and I indeed had run across this
in Jun 02. It is in my version of LIBC_A already but looking further
and checking Dave Walker's C68 websight, I don't see any updates in
that time frame.
In the meantime I had also found some issues with the following
In a message dated 04/01/04 17:03:38 GMT Standard Time, [EMAIL PROTECTED] writes:
However, there is another question (which I may be able to answer before
anyone else too). The addition of job events to SMSQ/E has caused a change
in
IOP.RPTR. This will now allow a return from a job event. The
Christopher Cave wrote:
I have been watching this exchange with trepidation since I have
been using wm_rptrt surrounded by many thousands of lines of
C68 code WITH NO PROBLEM. I was under the impression that
Jonathan Hudson had sorted this call out some time ago.
Actually I think it was
On 2 Jan 2004 at 11:51, [EMAIL PROTECTED] wrote:
(...)
Since the original IOP.RPTR asks for D2.B to be set, does this not mean that old
programs
calling the routine might find peculiar things happening? For example, the contents
of D2.L could
have $FF as the top byte. D2 might have
George Gwilt writes:
As everyone will realise by now, the events given to WM.RPTRT in D2.B are
job
events, not pointer events. So, obviously, WM.RPTRT will return on any
pointer event just as WM.RPTR does whatever the value in D2.B.
Sorry I wasnt more helpful but Ive been extermely busy
As everyone will realise by now, the events given to WM.RPTRT in D2.B are job events, not pointer events. So, obviously, WM.RPTRT will return on any pointer event just as WM.RPTR does whatever the value in D2.B.
However, there is another question (which I may be able to answer before anyone else
The PE vector WM.RPTRT is supposed to read the pointer in the same way as WM.RPTR with two additions.
1. It has a timeout (in D3.W)
2. It returns on the events set in D2.B
I find that although it correctly returns on timeout (with D0.L = -1), WM.RPTRT always returns on an event whatever the
P Witte makes some magical things to make me read
} Sorry for being such a pain, but I have some further questions:
}
} How do I position a PE window accurately? Problem is, I want to create a
} button, to go into the button frame. Im hoping to use a standard Window
} Definition with a single
On 27 Oct 2003 at 14:58, P Witte wrote:
I hadnt thought of that, (I dont yet have the new Qmenu). But Id still
prefer to know how to do it myself ;)
Fair enough.
if not, I've dug up some old code I hd used previously for a button
with a standard border
I feared, but was hoping I
In a message dated 26/10/03 20:52:57 GMT Standard Time, [EMAIL PROTECTED] writes:
Sorry for being such a pain, but I have some further questions:How do I position a PE window accurately? Problem is, I want to create abutton, to go into the button frame. Im hoping to use a standard
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
Wolfgang writes:
How do I position a PE window accurately?
Does the software have to be able to run on a machine
that may NOT have the menu extensions installed?
If not I suggest you use the menu extensions to set up your button.
(I could help you there)
I hadnt thought of that, (I
On 26 Oct 2003 at 20:51, P Witte wrote:
Sorry for being
such a pain, but I have some further questions:
How do I position
a PE window accurately? Problem is, I want to create a
button, to go
into the button frame. Im hoping to use a standard Window
Definition with
a single Loose
Wolfgang Lenerz writes:
What are the call and return parameters (all of them) for wm.rptrt
again?
Here are the notes I have on that
-
Vector $78 WM.RPTRT
How do I know Ive timed out?cmpi.w #-1,d0?
John Gilpin writes:
I have just checked in the Quanta library and the latest I can find is
Qmac
V1.06 and Qlink V1.03
Thanks for checking.
Per
Hi all,
What a shock to get back from a 10-day absence to discover nearly 200
ql-user mails in my inbox! My first thought was that something major had
happened, eg large chunks of Smsq/e source code had been discovered
at the heart of Windows and here was Bill Gates frantically trying to defend
P Witte wrote:
Also, can others confirm that the DATA directive in Qmac 1.06 doesnt work?
It works. You probably also have to include the line
filetype 1
If so, can this be fixed? Is 1.06 the current version?
Probably.
Marcel
I have just checked in the Quanta library and the latest I can find is Qmac
V1.06 and Qlink V1.03
John Gilpin,
Quanta Head Librarian.
- Original Message -
From: P Witte [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Friday, October 24, 2003 4:12 PM
Subject: [ql-users] wm.rptrt
Hi all
19 matches
Mail list logo
