Arrows keys sometimes ignored with Util.ReadLine

sgmoore

To reproduce, run the following script

var list1 = new List<string>() { "1", "2", "3" };
Util.ReadLine("Select Value", list1[0], list1);

Then press the down arrow key three times. The third keystroke correctly does nothing as they are no more items. However pressing the up arrow should change back to "2" but it doesn't do anything and you need to press it an extra time.

Similarly if you press up arrow when the first item is selected it takes two down arrows to move down.

Also, would it be possible to handle the following code better.

Util.ReadLine("Select Value", list1);

Even a compile-time error would be better than the current runtime error.

JoeAlbahari

I can't reproduce this. Are there any more clues you can provide?

Regarding this example:

Util.ReadLine("Select Value", list1);

I will add a hint to the runtime error message. I tried fiddling with the API but it seems that it's not possible to make this work - or even generate a compile-time error - without making breaking changes to the API. The difficulty is that the compiler binds preferentially to the generic overload, i.e., TResult ReadLine<TResult>(string prompt, TResult defaultValue)

sgmoore

I can't reproduce this. Are there any more clues you can provide?

Sorry this looks more complicated than I thought and the session must get into some state that then causes this bug within that process.

I can reproduce this using a script about 2000 lines which accesses a local web-service and also some local files. If I run this script and then start deleting lines, I can delete everything bare the two lines above and it still goes wrong, but it works correctly if I clone the two line query or if I restart Linqpad.

I'll have to investigate further.

sgmoore

Try this :

Util.ReadLine("Enter something and then press return");

var list1 = new List<string>() { "1", "2", "3" };
Util.ReadLine("Select Value", list1[0], list1); 

NB You do need to enter something on the first line as simply pressing return on the empty line does not trigger the issue.

JoeAlbahari

Thanks - this will be fixed in the next build.