Complete control of cmd windows

[einstein1969]

And better stay with 'echo prompt $E^| cmd.exe' for getting the escape character in order to continue supporting file names with special characters.

I did not understand, how should I do?

[einstein1969]

Another approach could be a creation of lnk file and editing the ConsoleaDataBlock : https://learn.microsoft.com/en-us/opens ... 8695e8dd0c - it requires binary editing of that block.

Here's an old C# hybrid that tickles the quick edit mode - https://github.com/npocmaka/batch.scrip ... ckEdit.bat

This also can be useful: https://www.pinvoke.net/default.aspx/ke ... tions.html

Hi npocmaka.

Unfortunately I'm not at your level. I would need a tutorial for these things. However, I really like the self-compiling of the code for small supporting executables.

[aGerman]

I did not understand, how should I do?

Recently you began using FORFILES to create the ESC character. Please don't. If you want to figure out why, rename your script to, say, "test %!&)^.bat" and you'll find the ESC not being created anymore
Instead use

Code: Select all

for /f "delims=" %%E in (
    'echo prompt $E^| cmd.exe'
  ) do (

etc.

[einstein1969]

thanks aGerman.

[aGerman]

FORFILES might still be useful if you want to create more C0 characters used in VT processing. In this case take a path which is supposed to not containing special characters. Such like /p "%__APPDIR__%." /m "cmd.exe".
viewtopic.php?f=3&t=10348&p=65991#p65991

[aGerman]

Since I gained some more experiences in this thread I'm about to refactor a few of the PS macros. There's one thing I'm still wondering though:
At the beginning of this thread you told that you've been facing a bug of PowerShell v.5.1 when it gets executed in a UTF-8 environment. From what I've read in the internet, this bug is gone with PowerShell Core (version 6 onwards). Do you have it installed by any chance? If so, can you confirm that this has been fixed if you replace the powershell.exe call with a pwsh.exe call in the macros?

What I'm considering right now is something like a simple ...

Code: Select all

for %%i in ("pwsh.exe") do if "%%~$PATH:i"=="" (set "ps=powershell.exe") else set "ps=pwsh.exe"

... and use the %ps% variable to prefer pwsh.exe whenever it is found.

[einstein1969]

Since I gained some more experiences in this thread I'm about to refactor a few of the PS macros. There's one thing I'm still wondering though:
At the beginning of this thread you told that you've been facing a bug of PowerShell v.5.1 when it gets executed in a UTF-8 environment. From what I've read in the internet, this bug is gone with PowerShell Core (version 6 onwards). Do you have it installed by any chance? If so, can you confirm that this has been fixed if you replace the powershell.exe call with a pwsh.exe call in the macros?

What I'm considering right now is something like a simple ...

Code: Select all

for %%i in ("pwsh.exe") do if "%%~$PATH:i"=="" (set "ps=powershell.exe") else set "ps=pwsh.exe"

... and use the %ps% variable to prefer pwsh.exe whenever it is found.

No I didn't have that kind of problem but you're okay to point it out here.

[aGerman]

Oh, I'm pretty sure you've been facing this bug. Look at post #5. Finally you worked around this issue by calling the macro before CHCP 65001. At least that's been my understanding. Hmm...

[einstein1969]

Oh, I'm pretty sure you've been facing this bug. Look at post #5. Finally you worked around this issue by calling the macro before CHCP 65001. At least that's been my understanding. Hmm...

Yes, I have that problem but I can't tell you why. The pc is new and I have not installed anything.
I think the change you proposed might be useful.

Code: Select all

PS C:\Users\fra> $PSVersionTable.PSVersion

Major  Minor  Build  Revision
-----  -----  -----  --------
5      1      19041  1682

[aGerman]

Win 10 and 11 still ship with "Windows PowerShell" (powershell.exe, ver. 5.1). However, Microsoft continues the development of PowerShell in the open source project "PowerShell Core" (pwsh.exe, currently ver. 7.2.6). While "Windows PowerShell" is known to behave unpredictable in a UTF-8 environment, "PowerShell Core" is said to have it solved.

For whatever reason I don't have these problems with "Windows PowerShell" on my Win 11. And I also don't have these problems with "PowerShell Core". So, it seems they have something fixed on Win 11 and thus, it's hard for me to tell if using "PowerShell Core" would fix the problem already on Win 10.

Nevermind, you certainly would have known if you installed "PowerShell Core". So I assume you did not.

[einstein1969]

Do you know if it is possible to handle mouse input in the dos window?

[aGerman]

I know how to do it in C. And everything that is possible in C is also possible in C#. And everything that is possible in C# is also possible in PowerShell. And PowerShell can be embedded in Batch code. However, it highly depends on the actual task if it is sensible or not. Think about the reaction time of doing those things in embedded PowerShell. If I had to write some code in these regards, I'd always prefer C. So, what would be your use case in particular?

[Aacini]

Do you know if it is possible to handle mouse input in the dos window?

My getinput.exe auxiliary .exe file has been handling mouse input for a long time now:

Code: Select all

Get input from both keyboard and mouse.

GetInput [/T msecs] [/I] [{"chars"|keycode}...]
         [ /M left top right bottom ... [/H [h1 h2 h3 ...]] ]

    /T msecs        Time to wait in milliseconds.
    /I              Ignore case of letters in given "chars" and keycodes.
    "chars"         Valid input Ascii characters.
    keycode         Valid input key code(s).
    /M l t r b ...  Coordinates of input selection boxes for mouse clicks.
    /H h1 h2 h3 ... Color attributes for "Hover" effect. See: COLOR /?

This program read input from keyboard and mouse and return it via ERRORLEVEL.

If no parameter is given, it waits for a key press or mouse button click and
return a value that indicate the input accordingly to the table given below.

If /T switch is given, it waits the maximum number of milliseconds specified;
if the value is zero, it returns immediately. If there is no previous input nor
new input in the given lapse, the returned value is zero.

Extended and cursor control keys can be specified via numeric key codes; see
the table of equivalences below. If /I switch is given, the letters in "chars"
string and keycodes use case-insensitive match.

If a list of valid input is given, it returns the *position* of the input key
in the list starting at one. If both characters and key codes are intermixed,
they all are numbered accordingly to their positions.

If a list of coordinates for selection boxes is given, the *position* of the
selected box in the list is returned starting at one; this means that the
valid keys and the selection boxes share the same values and there is no way
to distinguish they, unless both lists were specifically created to do so.

If /H switch is given, the "Hover" effect when the mouse pointer pass over the
selection boxes is enabled. The hover color will be a standard one, or several
colors may be given after /H switch for all boxes; if there are less colors
than boxes, the last color will be reused. The color at the first position of
a box will be used to redraw the original contents *of the whole box*.

Table of equivalences for input key codes given or values returned:

Keyboard keys have positive values.
- Control-keys in 1..31 range: Ctrl_C=3, TabKey=9, EnterKey=13, EscKey=27, etc.
  Shift_Tab (BackTab) is a special case; its value was choosen as 31.
- Ascii characters in 32..191 range: Space=32, A=65, a=97, etc.
- Alt-keys in 192..255 range: Alt_1=209, Alt_A=225, Alt_Z=250, etc.
- Extended-keys in 256..511 range:
  PageUp=289, PageDown=290, EndKey=291, HomeKey=292, LeftArrow=293, UpArrow=294
  RightArrow=295, DownArrow=296, InsKey=301, DelKey=302, F1=368, ..., F12=379.
  In Shift-extended key combinations, add 256: Shift_PageUp=545, etc.

Extended keys values use the Virtual Key Code value plus 256. See:
http://msdn.microsoft.com/en-us/library/windows/desktop/dd375731(v=vs.85).aspx

When no /M switch (list of selection boxes) is given, mouse button click
positions are returned as negative errorlevel values.

To get the position of a mouse click, use this method:
   GetInput
   if %errorlevel% gtr 0 (
      echo Key pressed: %errorlevel%
   ) else (
      rem Mouse button clicked
      set /A "input=-%errorlevel%, row=input >> 16, col=input & 0xFFFF"
      if !col! lss 32768 (
         echo LEFT button clicked at !row!,!col!
      ) else (
         set /A col-=32768
         echo RIGHT button clicked at !row!,!col!
      )
   )

To specify a right-button click in /M switch selection boxes, add 32768 to
column coordinates, that is, to both left and right ones. Screen coordinates
start in 0 0 at the left-top corner of the screen.

"GetInput Test.bat" program show the values of a series of keys/clicks:
http://www.dostips.com/forum/viewtopic.php?f=3&t=5330&p=32241#p32241

An example of the use of this program is shown in 2048.bat game at:
http://www.dostips.com/forum/viewtopic.php?f=3&t=5701&p=35407#p35407

And in this thread I describe a method to load a PowerShell engine just one time and reuse it from a Batch file many times, so the response time is almost the same as an auxiliary .exe file written in assembly language...

Antonio

[aGerman]

And in this thread I describe a method to load a PowerShell engine just one time and reuse it from a Batch file many times, so the response time is almost the same as an auxiliary .exe file written in assembly language...

That's the reason why I asked for the use case. Your technique works marvellously Antonio. However, it requires the executed batch code to be iterable since it performs a loop to read the output of the PowerShell code.

Steffen