[Top][All Lists]

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

Re: filter() prevents clearing of screen, but still clears current line

From: Christer Enfors
Subject: Re: filter() prevents clearing of screen, but still clears current line
Date: Mon, 19 Mar 2007 11:38:00 +0100
User-agent: Thunderbird (Windows/20070221)

Thomas Dickey wrote:
What I had in mind was making instring/outstring hide the details of how
they are interacting with the server.  The point of a server is that it
would be the only process to actually update the screen, so the problems
with clearing parts of the screen would just go away (unless there are
_other_ parts of the scripts that write to the screen - that would make
it not a good solution).

Right, that's how I would do it too. I don't think there are other things than instring / outstring that writes things on the screen. That would, as you say, ruin the setup.

But the first problem with this approach that I see is that it won't know when the legacy script is "done", so it won't know when to quit, and thus it won't know when it's time to "start over" - when a new legacy script is called, with another form.

Or... perhaps... if the first call to instring / outstring would trigger the starting of the server, and inform the server of the PID the legacy script has. Then the server could monitor that PID, and when the legacy process dies, the server dies too.

This reminds me of that university where the CS department kept a teddy bear. Students weren't allowed to ask the teachers for programming help until they'd explained the problem to the teddy. It turned out that around half of the students figured the problem out by themselves as they were explaining it to the teddy, thus reducing the number of students that had to ask a teach for help.

But the whole setup still feels kinda shaky. If it turns out that one of the legacy scripts use something other than outstring and instring to manipulate the screen, then everything would come crashing down.

However, there's another simpler approach too. I could dump ncurses all together for instring (which reads the input fields), and make a custom program for that, using scanf. I'd still use tput to move the cursor to the correct position on the screen, then I could just use a small binary that calls scanf(). But that problably won't work very well with arrow keys and whatnot. So I'd have to use libc's equivalence of getch() (whatever that's called), and handle things like backspace and arrow keys myself. That doesn't sound like fun.

Decisions, decisions!

Christer Enfors

reply via email to

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