Fixed v15.00.27: @SELECT

Jul 21, 2012
32
0
#1
First, thanks for adding the new functionality to @SELECT. Makes my movie db management tool much sleeker.

A minor bug with returned SELECT_LINE which is 0 based instead of 1 based.

Also, in the doc for @SELECT, the SELECT_LINE variable is not mentioned.

Cheers,
Gilad
 
Jul 21, 2012
32
0
#2
One more bug, it seems: [ENTER] doesn't register in the _SELECT_KEY variable. It just keeps its previous value. Might be WAD, as you chose to keep Enter and Escape work as usual, overriding the keymask functionality. I can live with that.
 

rconn

Administrator
Staff member
May 14, 2008
10,786
97
#3
One more bug, it seems: [ENTER] doesn't register in the _SELECT_KEY variable. It just keeps its previous value. Might be WAD, as you chose to keep Enter and Escape work as usual, overriding the keymask functionality. I can live with that.
WAD - _SELECT_KEY returns the last matching keystroke for an input mask. An Enter (or Escape) doesn't match anything.
 
Jul 21, 2012
32
0
#8
Not sure what you mean by "match F2 to a line". _SELECT_KEY should hold a keypress or a combination, not the contents of a line.

I would expect it to behave the same way as INKEY /K, except the navigational keys which should always behave as expected; and return the result key in INKEY format.
 
#10
That's definitely not what _SELECT_KEY does.

Perhaps it would be best if you described exactly how you think it should work, and how you would use it -- especially what you think would / should happen when you press a function key while doing string match.
A slight change of topic here, but I'm not seeing the behavior I would expect from @SELECT when I do NOT specify the keymask argument. In this case I would expect it to do string matching when I type as it does in V14, but in V15 nothing happens when I type. Is this not working correctly or is it a misunderstanding on my part? (This is build 29 under XP.)

-- Howard
 
Jul 21, 2012
32
0
#11
I noticed that too, Howard.

Rex, here's the behavior I expect for the different variations of the function:
1. When invoked without the 'keymask' parameter, the list box should react to navigational keys, Enter, Escape as expected. Normal character key presses and backspace should go directly to the Search box, and filter the list as expected, regardless of current focus within the list box.

2. When invoked with 'keymask', the list box should react to navigational keys as usual. When the user clicks on the search box, it allows normal typing only while the focus is in the box. Leaving the box keeps the filter active, but re-applies the keymask filter. Any other key is ignored, unless it is listed in the 'keymask'. When the user presses any key or key combination listed in keymask, it will immediately terminate @SELECT, and return the current line that was selected (or empty if all lines were filtered, or no line was supplied in the first place), and _SELECT_KEY holding the key/combination pressed, similar in format to INKEY's return value in its provided variable. One last note which I would add is that @SELECT should react to Ctrl-C just like any other command in TCC would - it should immediately close it, and pass the break to the batch file, just as a fail-safe mechanism to protect the user from his mistakes.

Best regards,
Gilad