|
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 1.5.0.10 (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
[Prev in Thread] | Current Thread | [Next in Thread] |