Re: Cursor not working with pads.

[Thomas Dickey]

On Sat, Dec 08, 2012 at 01:37:55PM -0500, Thomas Dickey wrote:
> 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.

hmm - it's more complicated than that :-)

You can see the Solaris source at opensolaris.org

Looking at wgetch and following it down, the SVr4 (old) source does not
mention pads.  But the XPG4 (xcurses) source does.  Both flavors of
wgetch call wrefresh near the beginning.  The xcurses source for wrefresh
in turn calls wnoutrefresh, which checks if the window is really a pad.
For that case, it simply returns an error.

Running the xcurses code (testing on Solaris 10), I see the same behavior
as ncurses: the box is not painted.  The SVr4 library paints the box.

Here's the likely reason for the difference:  it is helping with a case that
was not handled.  If one simply calls prefresh for the entire pad, it is still
necessary to know what the last prefresh's coordinates were - otherwise the
user gets a surprise.  The curses library is not doing that (since the relevant
information is not saved in the WINDOW structure).  ncurses _could_ do that,
but that would make it incompatible with other implementations.
 
> > > 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



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

signature.asc
Description: Digital signature