Capturing keys pressed from bat or cmd script

[Steve Millman]

Hi guys,

Am hoping someone has the means to replace an old program, which I used for batch file menus.. It was called Reply.com and it recognized the keys being pressed within a batch process, and returned a value for that key as Error Level.

In the batch file those values would guide the batch file to routines that would run programs, call other batches, etc.

I tried to recreate Reply.com in COBOL.
For those who do not know, the values you place into Return-Code in COBOL return to this DOS environment as ErrorLevel, so the setting was fairly straightforward.
But the COBOL app keeps wiping out my DOS screen, which contains a pretty text menu I build, showing the Function Keys and what functions they perform. (I have attached a sample of that batch menu below.).
i am using ACCEPT to capture the Function Keys in my version of Reply.com.

The code within the batch file did something like the following:

:GET-RPLY
REPLY
IF ERRORLEVEL 00 GOTO GET-REPLY
IF ERRORLEVEL 01 GOTO F1
IF ERRORLEVEL 02 GOTO F2
IF ERRORLEVEL 03 GOTO F3

routing the request based on the key pressed. (EL) ErrorLevel with a zero value is Enter key, EL 1= F1, EL 2 = F2. and so on.

Not sure if I can fix this in my reply.exe replacement program or if there is a different program that is avail that can do this.. but would be nice to be able to create external menu screens (rapidly) and then use a generic Reply program to identify keys pressed, and have a batch file act on those pressed keys.

Thank you,

Steve

[Simon Sobisch]

If I'm correct you use Arnold's MinGW 32bit build, correct? In this case you'd just need to swap pdcurses.dll (default: wincon port) by a version that was built identical, but the vt port (at least I think that kept the surroundings "intact").
@arn79: can you provide the pdcurses.dll's matching to your build for different ports?

[Arnold Trembley]

What I use for this is Microsoft's "choice.exe" program for CMD.EXE, which has been available since at least Windows Vista. I have certainly used it in Windows 7 and Windows 10. Open up a CMD.EXE window and type "choice /?" and you should get a help file that looks like the attachment.

You can also use the SET command for simple replies, something like the following:

:GETCHOICE
ECHO.
ECHO Are you sure you want to RESTORE FILES?
SET /P GETYN=[Y/N]?
IF /I '%GETYN%'=='N' GOTO CANCEL
IF /I '%GETYN%'=='Y' GOTO CHECKDRIVE
GOTO GETCHOICE

In the example above, SET /P GETYN=[Y/N]? means that GETYN is the environment variable you want to update, and "[Y/N]?" is the prompt that will be displayed. The "/I" option on the IF command makes the comparison case-insensitive, so Y, y, N, or n will work.

Here are some examples of using the CHOICE command to prompt for a reply, and then set the ERRORLEVEL based on the reply received:

Examples:
CHOICE /?
CHOICE /C YNC /M "Press Y for Yes, N for No or C for Cancel."
CHOICE /T 10 /C ync /CS /D y
CHOICE /C ab /M "Select a for option 1 and b for option 2."
CHOICE /C ab /N /M "Select a for option 1 and b for option 2."

As you can see, you can also set a timer with CHOICE that will create a default response if the user does not enter anything. CHOICE.EXE is normally found in the C:\Windows\System32 folder, and the 64-bit version is found in the C:\Windows\SysWOW64 folder.

[Anonymous]

Choice sounds great for Either or Responses; but I am looking for the means to tell that one of 12 or even more Keys have been pressed, and route accordingly.
This worked great in the DOS world. Very fast and easy... Am hoping to revive. Just need a way to suitably replace the old Reply.com app...

[Arnold Trembley]

CHOICE can handle 12 or more responses, provided that each response is a single character. Here's a simple example:

@echo off
:MAIN 
echo.
CHOICE /C 1234567890ABQ /M "Press Q to Quit."
echo.
echo Your ERRORLEVEL is %ERRORLEVEL%

if ERRORLEVEL 13 GOTO :ALLDONE 
GOTO :MAIN 

:ALLDONE 
echo. 

Note that "0" will set ERRORLEVEL to 10, "A" gets ERRORLEVEL 11, "B" gets ERRORLEVEL 12, and "Q" gets ERRORLEVEL 13.

[Anonymous]

Thanks Arnold. That would work. I wanted Function Key choices; but can
certainly live with this..
Will just have to restructure the Menu Screens to use Numbers or Letters
instead of Function Keys.

Have also been asking on other boards if anyone might have a Java program
or something similar
that would read Function Keys too. If I learn they do, and it works, I
will share with the group.

mod edit to remove some reply-to

[Steve Millman]

Wanted to share this with the group. An admin on another site posted this link:
https://github.com/TheBATeam/GetInput-By-Aacini?fbclid=IwAR1wiYXMbv79YcRlttDk5NwyrgswUDdaNLKcP5zfmoRi2IXpFlC7acGXVg8
to an app called GetInput, that does like my original Reply.com.. and returns an ErrorLevel code for any keys pressed.
This works well within a batch file, as does the Choice command, which Arnold describes below.
The difference between the two is that GetInput returns a value for any key pressed, allowing you to use that value to route your request to a function within your batch file, while Choice allows you to assign a value to a Number or Letter that corresponds to a function within your batch file.
In other words if I know that F1 was pressed.. I might route, based on that entry, to a function within my batch file. Whereas, with choice, if '1' or 'A', or whatever key I assigned to that function was pressed, I might route the code accordingly.
Either way, you will have more control within your batch files via use of these functions.

[Arnold Trembley]

Alternatively, if you want to try Simon's suggestion of using VT in PDCursesMod instead of WinCon, you can download a special version of GnuCOBOL 3.1.2 with BDB, from here:
https://www.arnoldtrembley.com/GC312-BDB-SP1-rename-7z-to-exe.7z

If you look at the directory for the \bin folder you will see the following DLL's:

07/05/2021 06:49 PM 180,788 pdcurses.dll
07/05/2021 07:21 PM 137,864 pdcurses_vt.dll
07/05/2021 06:49 PM 180,788 pdcurses_wincon.dll
07/05/2021 07:07 PM 197,769 pdcurses_wingui.dll

As you can see, the default "pdcurses.dll" file is the same length as the wincon pdcurses.dll.

You can switch between the WinCon, WinGUI, and VT versions by copying one of those dll's over the "pdcurses.dll" file. I have tested that and it works, but I still find the WinCon version of pdcurses.dll to be the most useful interface for DISPLAY and ACCEPT.

Kind regards,

[Anonymous]

Are those different than these:

Here too I can see that the default matches the WINCON version. Do I need
to download another 3.1.2.b? And if I do.. do I need to install it.. or
just borrow its PDCURSES files?

[Arnold Trembley]

Those are the correct files. All you need to do is choose one of the alternate pdcurses.dll files, and copy if over the normal default filename "pdcurses.dll". Obviously, you want to save all the special pdcurses.dll files so you can restore back.

You do NOT need to recompile ANY programs, because pdcurses.dll is called at runtime and the call interface is not changed.

So replacing the pdcurses.dll file with a different version will change the pdcurses behavior of an existing program. But you should only use these dll variants with the GnuCOBOL 3.1.2 compiler that came with all three variants in its \bin folder.

I hope that helps!

[Anonymous]

Thanks Arnold. I will give it a try. I am very happy with the DISPLAY and ACCEPT in the apps I have been running; but would like to see if they will still run the same AND allow the batch process to remain undisturbed while I check for Function keys. Not exactly sure why this would work.. as I dont know any of the background of these different DLLs.

[Brian Tiffin]

If you are using PDCurses, you might want to take a look at the PDC_PRESERVE_SCREEN and PDC_RESTORE_SCREEN environment variables. Supposedly, with PDC_PRESERVE_SCREEN set to any value, it will skip using an alternate curses screen, and withPDC_RESTORE_SCREEN it'll image the screen before an initscr, flash to the alternate, and then repaint what it captured after endwin.

I say supposedly, as I do not run PDCurses, but just remove the SMCUP and RMCUP entries from my favourite termcap entries on GNU/Linux. The nice thing about disabling SMCUP/RMCUP is that all curses based code will leave the screen alone. You can run things like man, find the critical bit of info you need, quit out and the data stays on screen. Helps a lot once you hit 50 and brain cells have about 0.001 seconds worth of short term recall. ;-) That, and GnuCOBOL screen section code stays on screen on program exit too. I recommend everyone disable SMCUP and RMCUP. The alternate shadow screen is more annoying than useful in my biased, over 50, opinion.

If you are using PDCurses, setting PDC_PRESERVE_SCREEN might be the easiest solution.

Have good, make well,
Blue

[Anonymous]

Thanks Brian (Blue),
Just not sure how far I want to stray off the path with these menus.
Was hoping that alternatively one of the dialects might work better than
another; but was wondering if I could set it within the actual Reply
program.
In Microsoft we could places a $SET statement in 7 (on first row of
program) and set compiler overrides.. Would be a lot more beneficial than
tailored compile batch jobs.. or the like.
Would like to not have to use different elements to make a system work..
since GnuCOBOL 3.12B seems to be working so well .
Steve

mod edit to remove some reply-to

[Simon Sobisch]

In Microsoft we could places a $SET statement in 7 (on first row of program) and set compiler overrides.

Actually GnuCOBOL allows the same for very common ones and also has some of its own. You may want to have a look at the Programmer's Guide and can see the details at https://sourceforge.net/p/gnucobol/code/HEAD/tree/tags/gnucobol-3.1.2/cobc/pplex.l and https://sourceforge.net/p/gnucobol/code/HEAD/tree/tags/gnucobol-3.1.2/cobc/ppparse.y - more supported with 3.x (upcoming 3.2).
The list could be extended - but we'd need some contributor that is so passionate about it to add those (there's no magic in doing so, but it is a bunch of work [I've recently added ODOSLIDE, so there are samples for that available]).

[Anonymous]

Hi Simon,
Apologies. I do not follow.. Can you provide an example or two of it
setup in column 7 properly?
I had tried $SET MF and also $SET MF ANSI85 and likewise $SET lklkjlkd
(random keys) and all compiled; but none seemed to alter my compile.
Steve

mod edit to remove some reply-to

[Brian Tiffin]

Here's the list of supported SET directives, pulled from the lexer.

  ADDRSV
  ADD-RSV
  ADDSYN
  ADD-SYN
  ASSIGN
  BOUND
  CALLFH
  CHECKNUM
  CHECK-NUM
  COMP1
  COMP-1
  CONSTANT
  DPCINDATA
  DPC-IN-DATA
  FOLDCOPYNAME
  FOLD-COPY-NAME
  MAKESYN
  MAKE-SYN
  NOBOUND
  NO-BOUND
  NOCHECKNUM
  NO-CHECKNUM
  NO-CHECK-NUM
  NODPCINDATA
  NO-DPCINDATA
  NODPC-IN-DATA
  NO-DPC-IN-DATA
  NOFOLDCOPYNAME 
  NOFOLD-COPY-NAME
  NO-FOLD-COPY-NAME
  NOSSRANGE
  NO-SSRANGE
  NOSPZERO
  NO-SPZERO
  OVERRIDE
  REMOVE
  SSRANGE
  SPZERO
  SOURCEFORMAT
  SOURCE-FORMAT

I don't think SET MF is supported, yet.

Cheers,
Blue

[Anonymous]

Thanks Blue.
I see nothing in this list that would change the program's screen behavior.
Thanks for explaining though.. Will lock that away til the proper time.
For now, the Choice command that Arnold presented, seems to work best.
Best Regards,
Steve

mod edit to remove some reply-to

[Simon Sobisch]

That looks like the list from 3.1.2, 3.2 should have some more. But yes, no "MF" there yet, but sounds like it would be possible to add, well patches welcome.

>> IMP STD name [STRICT] would look nicer for me and may fit GC better, but still: only will get in if someone contributes it...