On Tuesday, 10 January 2017 at 01:06:53 UTC, LouisHK wrote:
> So, I thought a little bit and I changed the terminal.d to check on the KeyEvent if the KeyEvent.bKeyDown is true, otherwise assigns a null event, and it's working fine and now I can get the ESCAPE key. :)

What line did you change? Maybe I can merge your change in, though I gotta make sure it doesn't break the key release events (which are supposed to be opt-in, so they should be ignored by default, but they are also supposed to be processable.)

On Monday, 9 January 2017 at 23:33:45 UTC, Era Scarecrow wrote:
>  For direct interactions (a game menu or similar) getting individual characters makes sense; I can't help but think Rogue-likes. However for data input (per line basis) or doing bulk data/processing, it doesn't work well.

Well, line processing depends on which level you're working on. My terminal.d includes a getline() function which gives the high level interface on a line level, but its implementation uses the individual events (and you can hook those for customization btw) because it allows the library to provide a much richer UX - line navigation with arrow keys, editing, insertion, etc.

Bulk I/O is a major win too, but with direct user interaction, the bottleneck is (almost always nowadays) the user's actual input - even quick typists are insanely slow sources of data as far as the computer is concerned. And there, being able to arrow, backspace, etc., is a huge productivity win for them and seeing the individual events gives the program the control it needs to make that work well.

On Tuesday, 10 January 2017 at 02:04:07 UTC, Adam D. Ruppe wrote:
> On Tuesday, 10 January 2017 at 01:06:53 UTC, LouisHK wrote:
>> So, I thought a little bit and I changed the terminal.d to check on the KeyEvent if the KeyEvent.bKeyDown is true, otherwise assigns a null event, and it's working fine and now I can get the ESCAPE key. :)
>
> What line did you change? ...

So, I was seeing and my version is a bit older than the one in the GitHub, but I looked over it, and I think you should put the code below at the line 1797[1]:

    if(!buffer[0].KeyEvent.bKeyDown){ return null ;}


So, it will stay inside the case KEY_EVENT: and will check the if KEY status is DOWN, otherwise will return null event.

Again this worked for me, but my terminal.d version is a bit older, and you may had already fixed, I can't change the version right now to test because I have some legacy code. But I'll try in another computer with the last version.

[1]: (https://github.com/adamdruppe/arsd/blob/master/terminal.d#L1797).

L.

On Tuesday, 10 January 2017 at 02:37:31 UTC, LouisHK wrote:
> Again this worked for me, but my terminal.d version is a bit older, and you may had already fixed, I can't change the version right now to test because I have some legacy code.

k. I try not to break things very often btw. terminal.d does have a minor change lately but code that worked on like any version over the last i think almost two years should keep working now. If I did it right.

On Tuesday, 10 January 2017 at 02:37:31 UTC, LouisHK wrote:
> So, it will stay inside the case KEY_EVENT: and will check the if KEY status is DOWN, otherwise will return null event.

So, the newest version of terminal.d already has a check for this... but you actually want to REQUEST key release events so kbhit doesn't clash with the system's release events.

Try this code on your version:

import arsd.terminal;
void main() {
	auto terminal = Terminal(ConsoleOutputType.linear);
	auto input = RealTimeConsoleInput(&terminal, ConsoleInputFlags.allInputEventsWithRelease);
	while(true) {
		if(input.kbhit()) {
			terminal.write(input.getch());
		} else terminal.write(".");
		terminal.flush();

		import core.thread;
		Thread.sleep(dur!"msecs"(50));
	}
}


It should give a steady series of dots unless you press a key. It should never stop giving dots (that means kbhit returned true when getch wouldn't actually return) and not print extra on release (though note that key repeat may give several down events as you hold it).


I might provide a helper function for that input thing eventually... but idk how yet, that RealTimeConsoleInput thing uses RAII to change terminal state so it cannot be copied - you always must pass by pointer, and I can't do that when returning from a function! Maybe I'll do a mixin to make the setup a bit simpler.

On Tuesday, 10 January 2017 at 14:48:39 UTC, Adam D. Ruppe wrote:
> ...
> Try this code on your version:
> ...

Well, I'm afraid to say that my version is older than you think:

Error: no property 'allInputEventsWithRelease' for type 'int'

Unfortunately there is no info in the terminal.d source so I could say how old it's precisely.

My main problem is that I can't upgrade DMD right now because the old projects that are running. I'm using DMD: 2.060!

Thanks,

L.

On Tuesday, 10 January 2017 at 22:14:47 UTC, LouisHK wrote:
> Well, I'm afraid to say that my version is older than you think:
>
> Error: no property 'allInputEventsWithRelease' for type 'int'

Oh yeah, I added that... I think a year ago.

> My main problem is that I can't upgrade DMD right now because the old projects that are running. I'm using DMD: 2.060!

Oh, I don't think you need to update dmd for the new terminal.d, you can copy yours though, then try the new one, and if it doesn't work just copy back to the old one.

But yeah, that's ok either way, your change fixes it for you, so you're good to go! That's one of the reasons why I like to keep my modules simple: so you can can edit them for your own purpose if you like.

On Tuesday, 10 January 2017 at 22:25:04 UTC, Adam D. Ruppe wrote:
> Oh, I don't think you need to update dmd for the new terminal.d, you can copy yours though, then try the new one, and if it doesn't work just copy back to the old one.

I already did that, but unfortunately it didn't work. Lacking some features.

> ... That's one of the reasons why I like to keep my modules simple: so you can can edit them for your own purpose if you like.

And thanks for this. I like your repo because that. It's so easy to import/try/change, like this one.

Thanks,

L.