I recently built PDCurses431 using the vt option because this was suggested as being possibly better than using the Wincon (console) version for use under Windows.
After doing the build of the vt PDC I then built GnuCOBOL 3.2 using the vt PDC - all built well although there doesn't seem to be any indication which version of PDC you are using - wincon, wingui or vt.
Compiling my favourite test program produced the following - I had to insert a pause in my compile batch file in order to capture the screen data.
Then the batch file runs the .exe and got this on the screen.
←[?47h←7←[1;1H←[0m←[40m←[37m ←[1;2H6m├Ü ←[1;7H *
The first display in the program is: Display " " line 1 col 1. and that's it.
I thought that there was NO display on the screen after the above although my program does a quite fancy display when run under wincon - HOWEVER - I was wrong.
The program output actually takes place in the very last column of this line:
←[?47h←7←[1;1H←[0m←[40m←[37m ←[1;2H6m├Ü ←[1;7H *
The * is the first character displayed after the " " indicated above - and IF I then press a key in response to my program - the whole of the program output gets displayed in that last character position (174 in my case) of the screen.
The normal screen display would look something like the attached. Somewhat reduced for privacy.
there doesn't seem to be any indication which version of PDC you are using - wincon, wingui or vt
Try cobcrun --verbose --info, which may not work when redirected to a file (which is the reason that the additional information is not integrated by default).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Knocked up the simplest prog I could - display * line 1 col 1 followed by an accept omitted stop run.
result was:
←[?47h←7←[1;1H←[0m←[40m←[37m* ←[1;2H←[1;1H←[1;1HPr
ess any key to continue . . .
This is my * I presume ?? ^ at the end of that first line.
Maybe I should try & translate it from VT code.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've initially thought that this is because your environment doesn't understand vt at all, but as it works after a keypress it seems that there's something "missing" in the end of that sequence (either in general or for your actual environment).
What is the environment you run this on? The way to see that is
ver
wmic os get Caption, CSDVersion, BuildNumber /value
Additional: plain cmd, powershell, mintty (I think that's the one from MSYS2), Windows Terminal, other? Can you please test this with other "terminals" then the one you've initially used?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Do you have the same rubbish withcobcrun -vi when executing that from powershell, mintty (MSYS2 shell or "Git Bash" if you have that installed) Windows Terminal?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Rebuilt PDCurses 431 adding the vt build & saving the files.
Rebuilt GnuCOBOL 3.2 using the vt PDC files - see cobcrun -vi attached.
There are 2 items in win 10 menu indicating Powershell - buth apparently run the same thing but start with different displays - I ran both with a batch file that sets the environment for a .exe to run at dos level - normally I use my file-manager to do this.
I took screen copies & text copies of the data displayed.
I've also attached my sample .cob prog & my exetest batch file to run it.
Attachments -
cobcrun.inf - showing using VTx00 pdcurses
DISPTEST.COB - Minimal test program - just displays * & accept omitted.
EXETEST.BAT - batch file for running the test prog under dos.
PS1.txt - captured text from running of first powershell.
PS1.jpg - screen capture of the same.
PS2.txt - captured text from running of second powershell.
PS2.jpg - screen capture of same.
Well that seems a waste of time.
I installed Windows terminal - which actually then goes on to run powershell - duh!
Changing to my drive & folder & getting the same obscure message about having to enter .\ before my batch file - I actually got it to run.
See the attached screen capture with my * sitting up there top left.
BUT - the moment I moved the bloody mouse - bang - the accept omitted that was holding the program up - suddenly got taken & the program ended.
Tried multiple times & no matter what - as soon as the mouse was moved the accept omitted took that and ended the program - that's a bit of a shame to say the least.
Well that seems a waste of time.
I installed Windows terminal - which actually then goes on to run powershell - duh!
You can see the difference when checking for example with Sysinternal Process Explorer: a "plain" cmd or powershell work with the conhost terminal; if you use Windows Terminal this isn't the case any more as it is providing the terminal abilities itself.
There is a dropdown symbol where you should be able to open command prompt, too and also a "settings" where you can set that cmd to be the default and also add additional entries (for example all three from MSYS2 if you have that installed and a plain msys one; others will likely also include cygwin, WSL entries and vs command prompt).
Last edit: Simon Sobisch 2021-12-08
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
So what should I set it to - I thought Windows terminal was a replacement for command prompt - not just another way of doing the same old.
I set it to command prompt & got the same old dos prompt - except when I ran the test program - like above under powershell - just moving the mouse caused the accept omitted to be taken - that's no use at all.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It is a replacement for the terminal "conhost.exe" that would normally be used.
And it seems like it provides you with a mouse-move event which conhost didn't.
Do you have COB_MOUSE_FLAGS set the default "1"? I assume that when setting it to "0" that "ending ACCEPT OMITTED by mouse event" doesn't happen any more, correct?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Sorry Simon - was waiting for an email from Sf but they never come - so came directly & saw this.
You're right - disabling the cob_mouse_flags in the exetest.bat disabled the mouse movement error -
However - we're not supposed to adjust that every time we expect to run a program that isn't expecting a mouse movement surely.
Running it in a dos prompt with the CMF set to 1024 doesn't cause a problem - so why in WT does it do so - hardly a replacement for conhost ??.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Additionally - I thought that having started this topic I would automatically be subscribed to it - obviously not the case - although I'm sure it's been that way before. ??.
Now it's working having clicked the box.
Last edit: David Wall 2021-12-08
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I recently built PDCurses431 using the vt option because this was suggested as being possibly better than using the Wincon (console) version for use under Windows.
After doing the build of the vt PDC I then built GnuCOBOL 3.2 using the vt PDC - all built well although there doesn't seem to be any indication which version of PDC you are using - wincon, wingui or vt.
Compiling my favourite test program produced the following - I had to insert a pause in my compile batch file in order to capture the screen data.
During the compile I got this on the screen:
Then the batch file runs the .exe and got this on the screen.
The first display in the program is:
Display " " line 1 col 1.and that's it.I thought that there was NO display on the screen after the above although my program does a quite fancy display when run under wincon - HOWEVER - I was wrong.
The program output actually takes place in the very last column of this line:
The * is the first character displayed after the " " indicated above - and IF I then press a key in response to my program - the whole of the program output gets displayed in that last character position (174 in my case) of the screen.
The normal screen display would look something like the attached. Somewhat reduced for privacy.
More to follow - maybe..
Last edit: Simon Sobisch 2021-12-08
Try
cobcrun --verbose --info, which may not work when redirected to a file (which is the reason that the additional information is not integrated by default).Ah - you're right - although even this is corrupted.
Last edit: Simon Sobisch 2021-12-08
Knocked up the simplest prog I could - display * line 1 col 1 followed by an accept omitted stop run.
result was:
←[?47h←7←[1;1H←[0m←[40m←[37m* ←[1;2H←[1;1H←[1;1HPr
ess any key to continue . . .
This is my * I presume ?? ^ at the end of that first line.
Maybe I should try & translate it from VT code.
I've initially thought that this is because your environment doesn't understand vt at all, but as it works after a keypress it seems that there's something "missing" in the end of that sequence (either in general or for your actual environment).
What is the environment you run this on? The way to see that is
Additional: plain
cmd,powershell, mintty (I think that's the one from MSYS2), Windows Terminal, other? Can you please test this with other "terminals" then the one you've initially used?see attached different versions - cmd / file manager / powershell
OK, so that looks like a cmd from current win10.
Do you have the same rubbish with
cobcrun -viwhen executing that from powershell, mintty (MSYS2 shell or "Git Bash" if you have that installed) Windows Terminal?sorry I deleted the vt cobol folder - I'll recreate it & test with PS & reinstall WinTerm.
Watch this space.
Rebuilt PDCurses 431 adding the vt build & saving the files.
Rebuilt GnuCOBOL 3.2 using the vt PDC files - see cobcrun -vi attached.
There are 2 items in win 10 menu indicating Powershell - buth apparently run the same thing but start with different displays - I ran both with a batch file that sets the environment for a .exe to run at dos level - normally I use my file-manager to do this.
I took screen copies & text copies of the data displayed.
I've also attached my sample .cob prog & my exetest batch file to run it.
Attachments -
cobcrun.inf - showing using VTx00 pdcurses
DISPTEST.COB - Minimal test program - just displays * & accept omitted.
EXETEST.BAT - batch file for running the test prog under dos.
PS1.txt - captured text from running of first powershell.
PS1.jpg - screen capture of the same.
PS2.txt - captured text from running of second powershell.
PS2.jpg - screen capture of same.
I'm working on trying Windows Terminal..
Well that seems a waste of time.
I installed Windows terminal - which actually then goes on to run powershell - duh!
Changing to my drive & folder & getting the same obscure message about having to enter .\ before my batch file - I actually got it to run.
See the attached screen capture with my * sitting up there top left.
BUT - the moment I moved the bloody mouse - bang - the accept omitted that was holding the program up - suddenly got taken & the program ended.
Tried multiple times & no matter what - as soon as the mouse was moved the accept omitted took that and ended the program - that's a bit of a shame to say the least.
You can see the difference when checking for example with Sysinternal Process Explorer: a "plain"
cmdorpowershellwork with theconhostterminal; if you use Windows Terminal this isn't the case any more as it is providing the terminal abilities itself.There is a dropdown symbol where you should be able to open command prompt, too and also a "settings" where you can set that cmd to be the default and also add additional entries (for example all three from MSYS2 if you have that installed and a plain msys one; others will likely also include cygwin, WSL entries and vs command prompt).
Last edit: Simon Sobisch 2021-12-08
So what should I set it to - I thought Windows terminal was a replacement for command prompt - not just another way of doing the same old.
I set it to command prompt & got the same old dos prompt - except when I ran the test program - like above under powershell - just moving the mouse caused the accept omitted to be taken - that's no use at all.
It is a replacement for the terminal "conhost.exe" that would normally be used.
And it seems like it provides you with a mouse-move event which conhost didn't.
Do you have
COB_MOUSE_FLAGSset the default "1"? I assume that when setting it to "0" that "endingACCEPT OMITTEDby mouse event" doesn't happen any more, correct?Sorry Simon - was waiting for an email from Sf but they never come - so came directly & saw this.
You're right - disabling the cob_mouse_flags in the exetest.bat disabled the mouse movement error -
However - we're not supposed to adjust that every time we expect to run a program that isn't expecting a mouse movement surely.
Running it in a dos prompt with the CMF set to 1024 doesn't cause a problem - so why in WT does it do so - hardly a replacement for conhost ??.
The "rubbish" in
cobcrun -viwas helpful, I've created the upstream issue https://github.com/Bill-Gray/PDCursesMod/issues/218 - I'm still interested to see if this works on different terminals.Additionally - I thought that having started this topic I would automatically be subscribed to it - obviously not the case - although I'm sure it's been that way before. ??.
Now it's working having clicked the box.
Last edit: David Wall 2021-12-08