[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: mvwprintw

From: Thomas Dickey
Subject: Re: mvwprintw
Date: Mon, 3 Apr 2006 13:38:57 -0400 (EDT)

On Mon, 3 Apr 2006, Bob Rossi wrote:

On Fri, Mar 31, 2006 at 02:53:44PM -0500, Thomas Dickey wrote:
On Fri, 31 Mar 2006, Bob Rossi wrote:

OK, here is the script file that has the error. I also have the the
output of unmap attached. I am having a little trouble reading these
files for the first time. I suppose I better get good at it.

See anything interesting?

I don't see the \E[1C split-up in this trace, but find it unusual to
see a long string of nulls (^@) after the chunk:

\E[60;8Hb main.c:777777777777

There's not much here to read:
        ^N and ^O switch to/from line-drawing mode
        \E[60;8H moves the cursor to cell 60,8
        \E[21D moves the cursor left 21 cells

The \E's are escape characters.  unmap renders all of the control
characters with either ^'s or \'s (it also makes a new line on each
escape character, to make it readable).

Referring back to your trace, I notice that the trace-level should be
high enough, but I don't see PutAttrChar lines in that.  I'd expect
to see those immediately before individual characters are emitted.

Sometimes I add temporarily another call to _trace there to show
the actual bytes that are written - which is what I was considering
advising you to do to explore whether ncurses is emitting the ^@'s.

Right now, I'd suggest checking to see if PutAttrChar (in ncurses/tty)
is really being invoked, or if there's some bug in the tracing, etc.

Hi Thomas,

Sorry I haven't got to the bottom of this yet. Hopefully I'll find the
problem today. Since the debug doesn't seem to be helping to much here,
what's the lowest level function I should be debugging to determine why
my screen is getting corrupted?

hmm - go back to my last explanation. The screen is being corrupted because either ncurses or some other code is writing bad data. If it is ncurses, you should be able to see it by tracing the low-level function PutAttrChar(), which is actually doing the output to the screen. The trace you sent should have showed PutAttrChar(), but did not.

I'd see why it did not, and fix that (perhaps I misread the trace-level).
Then see if PutAttrChar() is getting bad data, or making it bad - there's
one call to PUTC() in tty_update.c which is doing the work.

Thomas E. Dickey

reply via email to

[Prev in Thread] Current Thread [Next in Thread]