TERM=vt100 does not work for function keys F-5 and above.

After some experimenting, I found that TERM=xterm works the best. TERM=konsole works ok, but has a strange flicker problem at times. So I use TERM=xterm.

I'm running Suse linux, with a KDE konsole window as a terminal. To use this, type the following in your window:

TERM=xterm
export TERM

It doesn't need to recompile oc or any programs.

It turns out that the vt100 emulator handles F-1 through F-4 differently than it does for F-5 and above. Seems that the old VT52 (or some such) only had four F keys. When they came out with the VT100 they added the rest. But the added keys use a different escape sequence than the first 4 F keys.

Looking at screenio.c, it can already handle up to 64 F keys, with Ctrl Alt and Shift combinations. If the os will pass them through.

I'm good with the 12 I get. Plus the up and down arrows, page up and down, home, and end keys.

I've enhanced screenio.c and screenio.cpy to return the tab key as 2007 and the back tab key as 2008, for the extended Accept statement. I don't think the changes apply to the screen section Accept, and I did not test the screen section at all. I believe the screen section uses the tab keys internally to hop between fields. I need the same functionality with the extended Accept statements.

Does anybody want a copy of my changes? I'm giving them under the oc GNU lesser license to the oc community. No warranty of any kind, etc... We need testers to test
a) it does not mess up the screen section accepts
b) numeric fields still work (I accept all fields alphanumeric and do my own numeric validations)
c) secure fields (passcode prompts I don't use)
d) MS windows (I don't use)
e) other platforms (VAX, etc)
f) any other tests that can be thought up

Also, the user guide needs to be updated. Let me know if I can change this, or to whom to send the changes.

Yes, OC does a good job and yes, all OSes can give you something to do...
Good to hear that your problems went away.

I'm a little bit confused about your changes:
- If it's only about tab/back tab keys as 2007/2008 there should be only some lines changed.
- Why do you want to retest everything (that mainly hasn't to do with the necessary changes)?

Just some hints: the SCREEN stuff is in complete different functions, therefore it should not cause strange behaviour.

Please post patch files (I guess you've patched the feb09 version).

About your original problem:
Wouldn't it be useful if OC checks the current term settings and internally translates the key codes?
If yes, I guess you could come up with a patch for that, do you?

human

Here's the reason why I want to run many different tests. I wrote my first Cobol program in 1973, so I've been doing this a while. I've seen seemingly trivial changes that "don't need to be tested much" blow up in my face when they shipped. I worked at a software house with 3,000 customers. When that happened it was embarrassment X 3,000. I've learned to never trust software until q/a has tested it and signed off. Even then, almost all software contracts say "no warranty of any kind..." for a good reason. Plus I'm a newbe at how oc does things.

It's good to know that the accept field routine is separate from the screen section. I'd still let everyone know that the screen section isn't tested, just to keep it in the open. Let them decide what that means.

It would be nice if oc would interrogate the TERM= settings and handle the input stream for any and all. Especially because newbies often quit when something like that causes them grief. It's terribly frustrating when they want it to run right out of the box and they don't know where to turn.

But I have a feeling that it would be a major task. What I have now works, and makes me happy. Maybe we can put it on the to-do list for a later project.

Right now, I'd like to put in some other enhancements. For one, the End key should go to the last non-blank, instead of to the end of the field. And I'd like to see the Insert and Delete keys added, with full functionality like it does in Libre Office. I think I'm fixing to dive into the oc pool and start coding like a code monkey.

I'll post the files in a few days. Maybe with some more enhancements added.

mrcool;

OpenCOBOL can always use more $ make check tests. We can talk about format for autotest if you'd like. If your patch files get distribution, all builds of OpenCOBOL will get tested along with them.

For stree testing an OpenCOBOL modification...this is for anyone reading along that likes to experiment.

Then, all being well and a happy make install and ldconfig.


That'll do a world class job of testing for leaks in compiled code. Trivia: It's Viking ... val grinned, not grind. Valgrind is nice tool. Yayy vikings.

Now back to the practical side. Information below about the hardships of testing curses keyscans is belief and not rigorous research; happy to be corrected.

Testing the ins and outs of ncurses, pdcurses, curses can be tricky. DejaGNU might work, but emulating keyscans is more approximate than reliably accurate. CUnit tests have an interactive curses mode that lets the user do the typing.

If need be, DejaGNU is supported by the autotools in use by OC 1.1 and it probably won't be overly heinous adding it to Makefile.am. Likely more heinous getting any test tool to interact with screen io (in terms of keyscan) with confidence.

Looking forward mrcool.

From what I'm led to believe, numeric validation of key input is simply someone sitting down and writing the picture editor in C. Not a small task, but more grunt than wizardry. This may get easier once the community gets a collaboration site up and running. Taking wayyy too long now. I'd like to get the nod to open the 1.1pre-rel on SourceForge. Pending.

Cheers,
Brian

Yes, automated testing of software is the best thing that's happened to software development since the invention of the keyboard and they got rid of those card readers. Push a button, everything is retested. Nice.

It would be great if we can get these changes into the test suite. When I get something in, let's consider it further.

Oc does rudimentary numeric validation in extended Accept statements. Digits from '0' to '9' only, from what I can tell. So there's no check for '+' plus sign, '-' minus sign, or '.' decimal point. Then it would get into that whole discussion about how to handle swapped comma and decimal points in Europe. And the dollar sign, pound sign, yen sign, etc... all over the world. I don't think there's a compiler vendor in any language that can come up with a good industry standard about how to handle numerics.

I'd advise all developers out there to accept all numeric fields as alphanumeric and do your own numeric validations. That way it won't change when there's a change in compiler vendors. If your Cobol programs are successful with oc, it may be worth your while to buy a compiler on another platform and sell them there. I've changed Cobol compiler vendors so many times I can't even count. So what I'm saying is that oc should probably stay like it is. (I'll get off my soapbox now.)

I vote that the 1.1 pre-release should be put on SourceForge as a final release now. It's stable enough. Don't wait for my changes.