Curses question

[Martin Weitzel]

In article <551 at edpmgt.UUCP> gpitcher at 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 at mwtech.UUCP, voice: 49-(0)6151-6 56 83