thefeduke wrote:My intention is to assign a row number as a default selection and to use the timeout to simulate the results of a mouse-click on that row and then allow the existing structure to run its course.
GetInput return zero when a timeout occur as I said before, so such zero is
not related to anyone of the options. You may link the zero to anything you want via additional code (independant of GetInput operation).
thefeduke wrote:That fits into my philosophy of avoiding action hard-coded analysis of multiple return codes, based on one character choices. Rather than a optional arguments like the /T and /D of CHOICE, why not continue to let the data define the menu?
I am afraid I don't understand what you mean, but I think the code below is an example of "avoid action hard-coded analysis of multiple return codes". In this program the actions are not hard-coded, but defined as data in an array that may also be read from a file; note that this method have no relation to GetInput, so it may also be used on values read by CHOICE, or SET /P commands. The positions of the mouse selection rectangles are not hard-coded either, but calculated (and modified) at run-time, and the "default timeout selection" is assigned to the center rectangle.
Code: Select all
@echo off
mode con: cols=80 lines=39
setlocal EnableDelayedExpansion
set "action[0]=goto Timeout"
set "action[1]=set /A Top-=^!^!Top*2"
set "action[2]=set /A Left-=^!^!Left*3"
set "action[3]=set /A Left-=(Left-58>>31)*3"
set "action[4]=set /A Top-=(Top-25>>31)*2"
set "action[5]=goto Terminate"
set "SP= "
for /L %%i in (1,1,6) do set "SP=!SP!!SP!"
set F2=201 206 188 200
set F3=206 187 188 200
set F4=206 206 188 200
set /A Left=0, Top=0
:loop
set /A L1=Left+6, T1=Top, L2=Left, T2=T1+4, L3=L1+6, T3=T1+4, L4=L1, T4=T3+4
set "M="
for /L %%i in (1,1,4) do (
set /A R%%i=L%%i+6, B%%i=T%%i+4, L=L%%i+1, T=T%%i+1, R=R%%i-1, B=B%%i-1
set "M=!M! !L! !T! !R! !B!"
)
set /A L=L1+1, T=T2+1, R=R1-1, B=B2-1, Tp=Top+2
set "M=%M% %L% %T% %R% %B%"
(
cls
for /L %%i in (1,1,%Tp%) do echo/
echo !SP:~0,%Left%! UP
echo/&echo/&echo/
echo !SP:~0,%Left%! LEFT OK RIGHT
echo/&echo/&echo/
echo !SP:~0,%Left%! DOWN
for /L %%i in (1,1,4) do ColorBox !L%%i! !T%%i! !R%%i! !B%%i! /D !F%%i!
)
rem UP LEFT RIGHT DOWN ENTER
GetInput /T 9000 294 293 295 296 13 /M %M%
!action[%errorlevel%]!
goto loop
:Timeout
echo/&echo/
echo Timeout...
:Terminate
echo/&echo/
echo You selected this position
thefeduke wrote:Aacini wrote:GetInput.exe program turn off QuickEdit, Ctrl-C and LineInput modes at start and recover the original settings at end, so it doesn't require any manual adjustment on this point.
This is still a problem area for me. I have touched on this in a couple of posts, but now I have some experimental results to narrow the problem. Someone else may understand under the cover, but I can only document the behavior. I start with two shortcuts to the Command Prompt. I set the QuickEdit property of one OFF and the other ON before opening either window. The properties of the newly opened windows are as expected. Dragging the left mouse button is also a good indication. If you change the QuickEdit property of each window to its opposite, again everything appears as expected. The ugliness begins if you run find /?. Both windows have reverted to their newly opened state. Some other commands also wreak this havoc: FINDSTR, cmdwiz getQuickEdit and likely others. Remarkably, cmdwiz setquickedit does its function, but just the act of checking with cmdwiz getquickedit has a chance of flipping the setting depending on the originally opened state.
What does it all mean? Are there two sets of properties? The real boss comes out of hiding when angered? All of this means absolutely nothing to GetInput and MChoice as long as the /T switch of Getinput is not used. Otherwise my mouse is preempted by QuickEdit only if the window was originally opened with QuickEdit set ON. I cannot click, but I can cut and paste well.
Well, if this involved description means that "GetInput.exe fail when the cmd.exe window have the QuickEdit property set to ON and the /T switch is used", then YOU ARE RIGHT!
I confirmed this behavior
, so I carefully reviewed the description of
SetConsoleMode Win-32 API function I used to develop this program and I can
NOT found any error in my code! It seems that there are certain status combinations that are not documented. Then, I ignored the official documentation and completed some tests until I discovered that it is necessary to turn off
all status (excepting ENABLE_MOUSE_INPUT) in order for this method to work:
SetConsoleMode( hConsoleHandle, ENABLE_MOUSE_INPUT + ENABLE_EXTENDED_FLAGS ). After that, GetInput worked correctly always, don't matters the previous QuickEdit status.
I updated the GetInput.exe version in the .zip file at the
auxiliary .exe programs post; I suggest you to delete your GetInput.exe file(s) and download the .zip file again. Please, post the results with the new version.
Antonio