Path: utzoo!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!mcsun!unido!mikros!mwtech!martin From: martin@mwtech.UUCP (Martin Weitzel) Newsgroups: comp.unix.wizards Subject: Re: Curses question Keywords: key interpretation problems Message-ID: <882@mwtech.UUCP> Date: 16 Aug 90 14:44:52 GMT References: <551@edpmgt.UUCP> Reply-To: martin@mwtech.UUCP (Martin Weitzel) Organization: MIKROS Systemware, Darmstadt/W-Germany Lines: 77 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