| Re:< Note 166.1 by KONING::KONING "NI1D @FN42eq" >
The buffer is LONG. The following program works fine on
VMS versions earlier than 5.1 and on real terminals, but hangs on
DECterm. The problem is that the QIO doesn't complete even
though the complete escape sequence has been input. What's
really interesting is that shortening the length from 100 to 1
doesn't change anything. It still hangs!
C program:
char C, T[100];
main()
{T$Init();
T$Put("\033[c",3);
T$Startone(T,100);
T$Get();
T$Cancel();
}
Print_Mess()
{
}
Macro Routines:
.TITLE Terminal IO routines for SEDT
$IODEF
$SSDEF
$TTDEF
$TT2DEF
$MSGDEF
MBXBUFLEN = 1024
IN_DESC:
.ASCID /SYS$INPUT/
IN_CHAN:
.WORD 0
OUT_DESC:
.ASCID /SYS$OUTPUT/
OUT_CHAN:
.WORD 0
IN_BUF:
.BLKB 20
IN_BUFLEN=.-IN_BUF
IN_STATUS:
.WORD 0
.WORD 0
IN_IOSB:
.BLKQ 1
OLDMODES::
.LONG 0
.LONG 0
.LONG 0
OLDLINES=OLDMODES+2
OLDCOLS=OLDMODES+7
NEWMODES::
.LONG 0
.LONG 0
.LONG 0
ONEMASK::
.LONG ONEBUF
ONEBUF:
.LONG ^D32
.LONG ONEBITS
ONEBITS:
.LONG ^XFFFFFFFF
.LONG ^XFFFFFFFF
.LONG ^XFFFFFFFF
.LONG ^XFFFFFFFF
.LONG ^XFFFFFFFF
.LONG ^XFFFFFFFF
.LONG ^XFFFFFFFF
.LONG ^XFFFFFFFF
MANYMASK::
.LONG MANYBUF
MANYBUF:
.LONG ^D32
.LONG MANYBITS
MANYBITS:
.LONG ^XFFFFFFFF
.LONG ^X00000000
.LONG ^X00000000
.LONG ^X80000000
.LONG ^XFFFFFFFF
.LONG ^X00000000
.LONG ^X00000000
.LONG ^X00000000
GOT_CHAR::
.LONG 0
COUNT_BUFFER::
.WORD 0
.WORD 0
.LONG 0
MBX_NAME:
.ASCID /SEDT$TT_MBX/
MBX_CHAN:
.WORD 0
MBXBUF::.BLKB 20
MBXMSGLEN::
.BLKW
MBXMSG::
.BLKB MBXBUFLEN-22
MBX_IOSB:
.BLKQ 1
T$INIT::
;Assign the terminal channel, read the terminal modes and clear half duplex
; and line wrap
.WORD 0
$CREMBX_S CHAN=MBX_CHAN,LOGNAM=MBX_NAME,MAXMSG=#MBXBUFLEN,-
BUFQUO=#<MBXBUFLEN*10>
$ASSIGN_S DEVNAM=IN_DESC,CHAN=IN_CHAN,MBXNAM=MBX_NAME
$QIO_S CHAN=MBX_CHAN,ASTADR=MESSAGEAST,-
FUNC=#IO$_READVBLK,-
IOSB=MBX_IOSB,P1=MBXBUF,P2=#MBXBUFLEN
$ASSIGN_S DEVNAM=OUT_DESC,CHAN=OUT_CHAN
$QIOW_S CHAN=OUT_CHAN,FUNC=#IO$_SENSEMODE,P1=OLDMODES,P2=#12
MOVQ OLDMODES,NEWMODES
MOVL OLDMODES+8,NEWMODES+8
BICL #<TT$M_HALFDUP!TT$M_WRAP>,4+NEWMODES
BISL #<TT$M_EIGHTBIT!TT$M_NOBRDCST>,4+NEWMODES
BICL #<TT2$M_EDITING>,8+NEWMODES
BISL #<TT2$M_BRDCSTMBX>,8+NEWMODES
$QIOW_S CHAN=OUT_CHAN,FUNC=#IO$_SETMODE,P1=NEWMODES,P2=#12
RET
MESSAGEAST::
.WORD 0
blbc mbx_iosb,20$ ;read error, abort
cmpw mbxbuf,#msg$_trmbrdcst ;requeue if not broadcast
bneq 10$
movzwl mbxmsglen,r0
clrb L^mbxmsg(r0) ;terminate message with null
;
; call processing routine here
; short int mbxmsglen contians length of message
; char mbxmsg contains text of message
;
CALLS #0,g^PRINT_MESS
10$: $QIO_S CHAN=MBX_CHAN,FUNC=#IO$_READVBLK,astadr=messageast,-
IOSB=MBX_IOSB,P1=MBXBUF,P2=#MBXBUFLEN
20$: RET
MBXMSGADR::
.WORD 0
movl #MBXMSG,R0
RET
T$APPLICATION::
;Return 1 if the VMS application mode is on
.WORD 0
BITL #TT2$M_APP_KEYPAD,8+OLDMODES
BNEQ MODEON
MOVL #0,R0
RET
MODEON: MOVL #1,R0
RET
T$GETSIZE::
.WORD 0
MOVW OLDLINES,@8(AP)
MOVB OLDCOLS,@4(AP)
RET
T$STARTONE::
;Start an input QIO for a single character or escape sequence
.WORD 0
MOVB #0,Got_Char
$CLREF_S EFN=#3
$QIO_S CHAN=IN_CHAN,EFN=#3,ASTADR=READAST,-
FUNC=#IO$_READVBLK!IO$M_TRMNOECHO!IO$M_NOFILTR!IO$M_ESCAPE,-
IOSB=IN_STATUS,P1=@4(AP),P2=8(AP),P4=ONEMASK
RET
READAST::
;AST for read completed. Set the flag so that the application knows
.WORD 0
MOVB #1,Got_Char
RET
T$GET::
;Get the number of characters read in the last input
.WORD ^M<R2>
$WAITFR_S EFN=#3
MOVZWL IN_STATUS+2,R0
TSTB IN_STATUS+6
BEQL $1
ADDW IN_STATUS+6,R0
$1: RET
T$CANCEL::
;Cancel the QIO on the terminal channel
.WORD 0
$CANCEL_S CHAN=IN_CHAN
$QIOW_S CHAN=IN_CHAN,FUNC=#IO$_SETMODE,P1=OLDMODES,P2=#12
$DASSGN_S CHAN=IN_CHAN
$CANCEL_S CHAN=MBX_CHAN
$DASSGN_S CHAN=MBX_CHAN
RET
T$PUT::
;Write output to the terminal
.WORD 0
$QIOW_S CHAN=OUT_CHAN,FUNC=#IO$_WRITEVBLK!IO$M_NOFORMAT,-
P1=@4(AP),P2=8(AP)
RET
.END
|
|
RE: -1
If you're not gonna read this, then I guess it's OK to flame at
you.
SET FLAME/ON
First of all, it seems as though your problem was in DECterm and
not in DECwindows in general. I would have posted the questions
to the DECterm notesfile as posted in note 2.*.
Secondly, I don't think your previous note was really called for.
Did it ever strike you that maybe NOBODY had even seen this type
of problem before, hence the lack of replies ??? As it turned out,
DECwindows was not at fault (according to your reply) and it was
in fact VMS. I am sure that conference is more active because VMS
is, right now, used/recognized by more people. I am sure that is
going to change as DECwindows becomes more "popular".
Thirdly, it is not the scope of this confernce to fix/report bugs.
There is a QAR system for that and this conference is for
informational purpose, mostly. It may answer/solvee known bugs,
but the correct way to report a bug is by filing a QAR.
SET FLAME/OFF
I have used this conference numerous times to solved problems/issues
that I have had and find it a And with one less person monitoring
this conference, it makes it that much easier to access it :-)
+Joe_who_is_surprised_that_no_one_else_has_responded_yet+
and would be lost without it.
|