Normally a buffer is a chunk of memory set aside to accumulate data in the background untilI'll add LIFO here: Last in, First Out. a real life example would be loading a Truck. --> This is (in a way) the same as FILO, but it's more known as LIFO
at some point the main application reads from it there by emptying the buffer/memory chunk.
There are the most common types:
1. First In, First Out (FIFO);
The first data item in the buffer will be read first when the buffer is read.
2. First In, Last out (FILO);
The First data item in the buffer will be read last, meaning its like a stack of papers, you
need to remove the top sheets before you get to the bottom sheets, the first one.
etc.
A buffer is just a storage space with indexes to that when written to or read from these indexes
are managed to so the system will know where to put the next data item and where to read to
get the next data item.
In most systems, when both of these indexes are the same, it means the buffer is empty..
keyboard must have some kind of buffer? If key is pressed and held, how to limit the number of executions then? Say, to 3 or 4.OS only has generic controls, like the repeat rate that you've found, but it might not be sufficient for your own needs. In this case, you can make your own buffer, a queue for instance, where instead of directly processing all ReadKey directly, you enqueue it instead. Then, somewhere else another code dequeues key from this queue one by one, at the rate you control (a simple SysUtils.Sleep before next iteration should do). As a means of preventing DDoS, you can limit the size of the queue that when it's reached, any ReadKey result is simply discarded / ignored.
Currently, in my code, if I press and hold for more than a split second, say, zoom in button, graphs keeps being re-plotted. As my graphs are quite slow, when I release the key, I still have to wait while graphs continues being replotted number of times, whatever number of keystrokes is in the buffer I guess.
How to control that?
or is it controlled by OS?
OS only has generic controls, like the repeat rate that you've found, but it might not be sufficient for your own needs. In this case, you can make your own buffer, a queue for instance, where instead of directly processing all ReadKey directly, you enqueue it instead. Then, somewhere else another code dequeues key from this queue one by one, at the rate you control (a simple SysUtils.Sleep before next iteration should do). As a means of preventing DDoS, you can limit the size of the queue that when it's reached, any ReadKey result is simply discarded / ignored.
you are right, slowing the repeat rate wasn't good idea. I forgot that same computer is used by many technicians for some other needs too, and everybody is used to a certain speed.The downside of graph unit (alongside crt) is that they're not friendly with the KVM (keyboard, video, mouse) units. Both units manipulate everything in their own incompatible way. So indeed if you have to use graph and crt, stick to everything they have.
I tried to play with keyboard unit (TKeyEvent etc.) but this doesn't work with GRAPH unit. How else I can make my custom logical buffer?
The easiest solution turned out to be "while KeyPressed Do Key := ReadKey; " where "Key" is declared as char type. This way there is no stored repeat keys, direct control.
I don't understand how it works, but it has desirable effect. I am getting used to not understanding things.
thank you Leledumbo. It works. You are using some syntax FPC compiler doesn't accept though. Like SysUtils need to be declared, can't call SysUtils.Sleep() directly. And then since it is declared, I can just call Sleep().
thank you Leledumbo. It works. You are using some syntax FPC compiler doesn't accept though. Like SysUtils need to be declared, can't call SysUtils.Sleep() directly. And then since it is declared, I can just call Sleep().What version are you using? I only test on latest stable and latest trunk, nothing prior to them. And surely both work as expected.
I remember C# is like that, no need to declare if you don't mind typing the whole thing every time. FPC apparently not. Maybe in Delphi it is possible?It's just for clarity, FPC and Delphi are the same in this regard, no need to qualify if you're sure which one to call of you want to override through the uses clause order.
A bit of mind-bending though, how it works. In your example, in my mind, as soon as you handle it to function PrintChar(), user is stuck in infinite loop. But, keyboard input is still handled, in parallel?Yep, more or less is like that.
What version are you using? I only test on latest stable and latest trunk, nothing prior to them. And surely both work as expected.
I just tried Leledumbo's program with FPC 3.3.1 and 3.2.2. Both compiled it and the resulting executables ran as expected.
However, there was an illegal character I had to remove close to the top.
The 0xC2 at offset 0x14.
What version are you using?
It's just for clarity, FPC and Delphi are the same in this regard, no need to qualify if you're sure which one to call of you want to override through the uses clause order.
So, the call SysUtils.Sleep() is not possible without including SysUtils in uses. I checked other calls, too. Mouse.GetMouseY does not compile without including mouse in uses. I definitely misunderstood what you were talking about, please expand on what you meant here:<unit name>.<identifier> is a way to explicitly say where the compiler should look the identifier for, regardless of uses clause order. So if you have: