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.
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?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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:
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.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
Anonymous
-
2021-09-22
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...
Last edit: Simon Sobisch 2021-09-23
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
CHOICE can handle 12 or more responses, provided that each response is a single character. Here's a simple example:
@echooff:MAINecho.CHOICE/C1234567890ABQ/M"Press Q to Quit."echo.echoYourERRORLEVELis%ERRORLEVEL%ifERRORLEVEL13GOTO:ALLDONEGOTO:MAIN:ALLDONEecho.
Note that "0" will set ERRORLEVEL to 10, "A" gets ERRORLEVEL 11, "B" gets ERRORLEVEL 12, and "Q" gets ERRORLEVEL 13.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
Anonymous
-
2021-09-24
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
Last edit: Brian Tiffin 2021-09-24
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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,
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
Anonymous
-
2021-09-22
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?
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!
Last edit: Arnold Trembley 2021-09-24
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
Anonymous
-
2021-09-22
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.
Last edit: Simon Sobisch 2021-09-23
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
Anonymous
-
2021-09-23
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
Last edit: Brian Tiffin 2021-09-24
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
Anonymous
-
2021-09-25
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
Last edit: Brian Tiffin 2021-09-26
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
Anonymous
-
2021-09-26
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
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...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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
Last edit: Steve Millman 2021-09-22
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?
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:
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.
Last edit: Arnold Trembley 2021-09-22
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...
Last edit: Simon Sobisch 2021-09-23
CHOICE can handle 12 or more responses, provided that each response is a single character. Here's a simple example:
Note that "0" will set ERRORLEVEL to 10, "A" gets ERRORLEVEL 11, "B" gets ERRORLEVEL 12, and "Q" gets ERRORLEVEL 13.
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
Last edit: Brian Tiffin 2021-09-24
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.
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,
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?
Last edit: Simon Sobisch 2021-09-23
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!
Last edit: Arnold Trembley 2021-09-24
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.
Last edit: Simon Sobisch 2021-09-23
If you are using PDCurses, you might want to take a look at the
PDC_PRESERVE_SCREEN
andPDC_RESTORE_SCREEN
environment variables. Supposedly, withPDC_PRESERVE_SCREEN
set to any value, it will skip using an alternate curses screen, and withPDC_RESTORE_SCREEN
it'll image the screen before aninitscr
, flash to the alternate, and then repaint what it captured afterendwin
.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
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
Last edit: Brian Tiffin 2021-09-24
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]).
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
Last edit: Brian Tiffin 2021-09-26
Here's the list of supported SET directives, pulled from the lexer.
I don't think SET MF is supported, yet.
Cheers,
Blue
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
Last edit: Brian Tiffin 2021-10-03
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...