WAD /T timer assumes 1st column position

[Claire_CJS]

The /T timer on inkey is great!

However, the timer resets the cursor position to column 1, instead of the column where inkey was called

So the timer ends up overwriting the prompt text, in my situation.

I believe the preferred behavior should be that the timer outputs at the current cursor position — That way we can have input questions where the timer doesn't overwrite the question.

test code:

echos Setting up an inkey mid-line ... %+ inkey /x            /c /k"yn[Enter]" %%ANSWER
echos Setting up an inkey mid-line ... %+ inkey /x /W9999     /c
echos Setting up an inkey mid-line ... %+ inkey /x /W9999 /T  /c /k"yn[Enter]" %%ANSWER

 

[vefatica]

The same thing happens with PAUSE.

 

[Claire_CJS]

I'm thinking it probably happens with any timer invoked by /T across the board.

 

[rconn]

WAD.

/T will first print a CR (going back to the start of the line), then the prompt specified, then the countdown timer, then wait for a key input.

 

[Claire_CJS]

Then it really feels like a design flaw.

Many prompts are in the form of:

"Do you want to do something [Y/N]? "

But now it's impossible to do this with a timer.

I mean, unless you insert the right number of spaces before the question... which is pretty janky, but I managed to make it happen to backfill this awesome new functionality into my "askyn.bat" general prompting.BAT, like so:

        set TIMER_SPACER=      ``
        IF %WAIT_TIME gt 9     (set TIMER_SPACER=%TIMER_SPACER% ``)
        IF %WAIT_TIME gt 99    (set TIMER_SPACER=%TIMER_SPACER% ``)
        IF %WAIT_TIME gt 999   (set TIMER_SPACER=%TIMER_SPACER% ``)
        IF %WAIT_TIME gt 9999  (set TIMER_SPACER=%TIMER_SPACER% ``)
        IF %WAIT_TIME gt 99999 (set TIMER_SPACER=%TIMER_SPACER% ``)

And then echoing %TIMER_SPACER% to push the question those many spaces over to the right..

Of course, this means the character you enter now appears on the screen prior to the question.

Though some creative use of Windows Terminal's ANSI features can have you save position, erase the characters, then fill the awkward blank space with the answer, which I did like this:

        inkey /x %WAIT_OPS% /c /k"%ALLOWABLE_KEYS%" %%OUR_ANSWER
        if "%OUR_ANSWER" eq "y" (set OUR_ANSWER_PRETTY=%ANSI_BRIGHT_GREEN%%DOUBLE_UNDERLINE_ON%Yes%DOUBLE_UNDERLINE_OFF%!)
        if "%OUR_ANSWER" eq "n" (set OUR_ANSWER_PRETTY=%ANSI_BRIGHT_RED%%DOUBLE_UNDERLINE_ON%No%DOUBLE_UNDERLINE_OFF%!)
        if %WAIT_TIMER_ACTIVE eq 1 (echos %@ANSI_MOVE_TO_COL[1]%TIMER_SPACER%%@ANSI_MOVE_TO_COL[1]%ANSI_BRIGHT_WHITE%%ITALICS_ON%%OUR_ANSWER_PRETTY%%ITALICS_OFF%%BLINK_OFF%%ANSI_POSITION_RESTORE%)

At least it's cute. I also got the timer blinking in red.
Still wish it wasn't where it was, though.

 

[Jay Sage]

I, too, encountered this. The solution was simple: Instead of using ECHOS to display the prompt, I put the prompt into the INKEY command. Without the /T option it doesn't matter, and I usually found the code easier to write using ECHOS to produce the prompt followed by INKEY without a prompt.

 

[Claire_CJS]

So many people having to use workarounds might be an indicator that the design here is less than intuitive.

 

[rconn]

The "workaround" is to use INKEY to display the prompt, not some random other command that INKEY is supposed to automagically interpret.

This is not new behavior; it was added in v31 and matches the original feature request. Your preference would require a breaking change (which won't be done). If you want to suggest an additional option to INKEY to tell it to use a timer but instead infer that a prompt was done by some other command, you can request it in the Suggestions Forum.

 

[Claire_CJS]

I do wish I'd properly read the inkey doc before embarking on yesterday's endeavors.

I just re-did it all and now the timer is in a much better place.


Thanks!