Re: mvwprintw

[Thomas Dickey]

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:
> >
> > \n^N^O~^Nx^O
> > \E[27;4H^N^O
> > \E[60;8Hb main.c:777777777777
> > \E[21Db
> > main1Cc:address@hidden@address@hidden@address@hidden@address@hidden@address@hidden@address@hidden@address@hidden@address@hidden@address@hidden@address@hidden@address@hidden@address@hidden@address@hidden@address@hidden@address@hidden@^@
> >
> > 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
http://invisible-island.net
ftp://invisible-island.net