geller@eli.UUCP (David P. Geller) (01/15/87)
Can the curses library of functions be effectively used to draw special characters on the screen that require two or more characters. In other words - if I draw a box using, say, escape sequences (where these characters don't advance the cursor position) - will I be able to coerce curses into properly redrawing the screen? Initial observation and experimentation indicates that the optimization facility inherent to the library ruins the drawing to special characters (curses says: why draw another escape character here when there is already one drawn...) Many thanks - and I'm happy to be back on the net after two years using a little tiny unix systems that didn't have the news software.... David P. Geller Electric Logic, Inc. Washington, D.C. ..!seismo!sundc!eli!geller
nevin1@ihlpb.ATT.COM (Liber) (04/01/89)
We have a program which uses curses for an interface. Some of the users of this program, however, use a program similar to tee (but it understands both input and output) as part of their environment. The curses-based program won't work with this other program, however. Does anyone know of a way around this problem? Thanks, and please respond via email to iee-help@wham.ATT.COM (if you are using reply, substitute wham for ihlpb and iee-help for nevin1), as I will be on vacation next week. -- _ __ NEVIN ":-)" LIBER nevin1@ihlpb.ATT.COM (312) 979-4751 IH 4F-410 ' ) ) "I will not be pushed, filed, stamped, indexed, / / _ , __o ____ briefed, debriefed or numbered! My life is my own!" / (_</_\/ <__/ / <_ As far as I know, these are NOT the opinions of AT&T.
gpitcher@edpmgt.UUCP (Glenn Pitcher) (08/15/90)
(editor's note: This may be a duplicate transmision. Sorry if you got it
twice)
I'm attempting to write my first curses program and have already run into
a couple of problems.
The first one involves interpretation of input keys. How can one tell the
difference between the forward and backward tabs?? When I run my test
program, I get 0x09 for both. In addition, the code I'm getting in my
test program for a return is different that the code which is returned in
the real program (0x0a vs. 0x0d) and yes, these two programs are being run
on the same system.
Sooo, could some curses guru out there possibly tell me what's going on???
Thanks,
--
Glenn Pitcher UUCP: {crash,ucsd}!edpmgt!gpitcher
Programmer/Analyst & hp-sdd!teamnet!gpitcher
Unix Guru in training
EDP Management, Inc. * Proud member of Team.Net *
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-guy@auspex.auspex.com (Guy Harris) (08/16/90)
>(editor's note: This may be a duplicate transmision. Sorry if you got it >twice) I only saw it once, but I did see the matching posting in "comp.sys.sun".... >The first one involves interpretation of input keys. How can one tell the >difference between the forward and backward tabs?? When I run my test >program, I get 0x09 for both. As noted, the problem here is that in a "shelltool" window, there *is* no difference. What's more, different terminals may transmit different things for the "backward tab", assuming they even have one; the BSD "curses" doesn't have any way of recognizing the particular terminal's notion of a "backward tab" sequence and translating it into some common code for "backward tab". The S5 "curses" might be able to do that. >In addition, the code I'm getting in my test program for a return is >different that the code which is returned in the real program (0x0a vs. >0x0d) and yes, these two programs are being run on the same system. But probably *not* with the same modes. 0x0a is NL, and 0x0d is CR. The RETURN key on most terminals - including the "terminal" emulated by a "shelltool" - sends CR; however, in some modes the UNIX tty driver turns CR into NL. Check out such "curses" functions as "nl()" and "nonl()", which affect whether this mapping is in effect....
martin@mwtech.UUCP (Martin Weitzel) (08/16/90)
In article <551@edpmgt.UUCP> gpitcher@edpmgt.UUCP (Glenn Pitcher) writes: >(editor's note: This may be a duplicate transmision. Sorry if you got it >twice) > >I'm attempting to write my first curses program and have already run into >a couple of problems. Which curses? There are (at least) three versions with some differences: a) The "old" (or Ken Arnold's) Curses, aka "termcap-curses" b) The new System V curses from Release 2, aka "terminfo- curses" c) The (slightly) enhanced version from Release 3.2, aka the ETI-Library (ETI = Extended Terminal Interface) >The first one involves interpretation of input keys. How can one tell the >difference between the forward and backward tabs?? When I run my test >program, I get 0x09 for both. Though you didn't tell if you activated the "keypad()"-support, it sounds as if the terminfo-entry is not correct for the terminal (assuming you use b or c from the above). >In addition, the code I'm getting in my >test program for a return is different that the code which is returned in >the real program (0x0a vs. 0x0d) and yes, these two programs are being run >on the same system. Again I can only guess, but there is a runtime-option which you can toggle with the "nl()" and "nonl()" function of the curses library. Maybe one of your programs does so, the other does not. >Sooo, could some curses guru out there possibly tell me what's going on??? I don't consider me a curses guru (I've some experience, thats all :-)), but sometimes it requires supernatural abilities to figure out what the poster might have made wrong. So please, and that's to *all* of you who post your questions: If you have some programming problem 1) try first to find the "smallest failing case", ie. derive a small program that demonstrates what you consider the wrong behavior (or in a way you don't expect.). Normally, 20 to 40 lines or so should well be sufficient(1,2). (As it seems from the above, the poster had done this as he mentions a "test program" and a "real program". Why didn't he post?) 2) Post this small piece of code together with some short information about your system. This need not be very detailed, but at least it should include the name of the OS you use, and the release number, and, if the problem might have to do something with hardware, give the respective informations too (eg. in the above case the brand of terminal on which the program is run would also be of interest). 3) In some cases a test run with some sample input and output would help to determine what goes wrong, but this is of course not appropriate here, as the verbal description is sufficient). There are many people here who are willing to help you. The more specific your request is, the faster and more precise we can answer. Remark 1: If you don't manage to put the smallest failing case in 20 to 40 lines, ie. if you can't reproduce the problem in a small test program, your failing program is possibly so mangled, that it's not worth the time to dig into it to try to find the bug. (Exceptions emphasize this rule.) Remark 2: It will often turn out, that in the process of trying to find the smallest failing case, you will find the problem by yourself and need not post. Of course, if you find something that seems to be an interesting bug, ie. something that behaves contrary as described in the manuals, you may well post this to the appropriate bug groups. -- Martin Weitzel, email: martin@mwtech.UUCP, voice: 49-(0)6151-6 56 83