bug-ncurses
[Top][All Lists]
Advanced

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

Re: Cursor not working with pads.


From: Thomas Dickey
Subject: Re: Cursor not working with pads.
Date: Sat, 08 Dec 2012 13:37:55 -0500
User-agent: Mutt/1.5.20 (2009-06-14)

On Fri, Dec 07, 2012 at 04:34:24AM -0500, Thomas Dickey wrote:
> On Thu, Dec 06, 2012 at 06:49:14PM -0800, Josh_Bresben wrote:
> > 
> > Sorry to send another message but I am really desperate to figure this issue
> > out. I've tried so many different things to no avail. I won't send another
> > message after this but I thought I would try again. The link to the code
> > with the problem is in the previous post I made.
> 
> I generally do ncurses work on Saturdays...
> 
> In a quick check, I see the program behaves as you describe,
> and that (the default) Solaris curses behaves differently.
> 
> It'll take some investigation to see what the difference is due to.

The problem is (long ago) from this as noted in man newpad:

       cur.   It  is not legal to call wrefresh with a pad as an argument; the
       routines prefresh or pnoutrefresh should be called instead.  Note  that
       these routines require additional parameters to specify the part of the
       pad to be displayed and the location on the screen to be used  for  the
       display.

and this in man wgetch:

       If the window is not a pad, and it has been moved or modified since the
       last call to wrefresh, wrefresh will be called before another character
       is read.

I don't recall the problem (not repainting the screen) being discussed before.

For existing versions of ncurses, you should be able to work around this
using prefresh (with appropriate arguments) just before the wgetch.

I've started investigating how to modify ncurses to do this automatically,
and match Solaris' behavior better.

> > Josh_Bresben wrote:
> > > 
> > > Thanks for responding, the following code is a stripped down version of
> > > the code that is causing the problem. As stated,
> > > the problem is that I am manually setting the cursor with wmove() in this
> > > code but the visual cursor stays at (0,0). Thanks for any advice you give
> > > with regards to resolving this issue. It's really bugging me.
> > > 
> > >  http://pastebin.com/r12eTyeV Here is a link to the pasted code. 
> > > 
> > > 
> > > Thomas Dickey-2 wrote:
> > >> 
> > >> On Mon, Dec 03, 2012 at 08:15:25PM -0800, Josh_Bresben wrote:
> > >>> 
> > >>> Hello,
> > >>> 
> > >>> I've set up a pad that I use to scroll to different content by calls to
> > >>> prefresh(). Everything about the pad works except for one visual issue:
> > >>> I am
> > >>> able to logically set the cursor to be in the proper subpads of the main
> > >>> scrollable pad (i.e. areas where the user can type) by calling wmove();
> > >>> that
> > >>> works just fine. However, the visual blinking cursor that actually lets
> > >>> the
> > >>> user know where he/she is remains at the origin (0,0).
> > >>> 
> > >>> I've even tried taking out all calls to wmove() and making the visual
> > >>> cursor
> > >>> move to a random spot like (4,9) and then calling refresh(), but the
> > >>> visual
> > >>> cursor just stays at the origin. Is there something extra that I have to
> > >>> do
> > >>> when using pads in order to get cursor movement functioning correctly?
> > >> 
> > >> The usual reason for the cursor appearing in the wrong place is from
> > >> using getch() rather than wgetch().  The latter allows you to specify
> > >> the window from which input should happen.  If it's not that simple,
> > >> a short program demonstrating the problem would be helpful.

-- 
Thomas E. Dickey <address@hidden>
http://invisible-island.net
ftp://invisible-island.net

Attachment: signature.asc
Description: Digital signature


reply via email to

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