So I am trying to detect when VK_BACK is held so it can delete a full sentence for example if i type 'I am typing this.' and hold down backspace it will only delete the word 'this' but if i single press backspace it deletes each letter as it should.
Is the \b method not good or is there an error in my code or what? I have tried a few things with no hope so here i stand in hopes of help.
1 2 3 4 5 6 7 8 9 10 11 12 13
case VK_BACK:
send(tsock, "\b \b", sizeof("\b \b"), 0);
while (true)
{
if (GetAsyncKeyState(VK_BACK) == WM_KEYDOWN)
{
send(tsock, "\b \b", sizeof("\b \b"), 0);
}
else
{
break;
}
}
Edit: As well note the case controlling VK_BACK is hooked into the keyboard I am only using GetAsyncKeyState() to detect if the key is held down or not
No, I don't want it to delete 2 characters I just want it to remove the char from the console window. If you type 'Typing' and do \b it allows you to write over the g but doesn't make it disappear until someone writes this is supposed to replace it with space so you don't see it and you can still replace it with what you type? If that makes sense? and what i need is for this to delete a whole sentence when holding down backspace which it doesn't do
An example of what it is doing:
User Types->'I am typing this'->Holds Backspace->Only 'this' is deleted in console whilst the whole sentence is deleted in the program they wrote it on.
An example of what i want it to do:
User Types->'I am typing this'->Holds Backspace->Whole sentence is deleted both in Console and in the program they are typing.
(The 'program' in these examples can be notepad or something of the sort)
not sure right this sec but I think backspace key behaves differently in notepad vs the console. Need to see what notepad does/expects to do the operation and send that. I wonder if you can send vk_back out... maybe that will do the right thing?
Not necessarily notepad but in any application, if you hold down backspace it will correctly send it each time. I think it's because the socket can't send fast enough to be able to keep up with all the backspaces or it's not reading the case fast enough i guess. I am about to test these theories and i will edit with results
Edit: When printing to console (Not sending) It prints the correct amount more even yet with the socket it isn't what would be a solution to this?
Is it on the same machine? You can get the process ID and directly send it a windows message (I think its wmkeypress) and you can use directinput to make it all very efficient, almost as fast as device to program. You can basically have your code spoof the other program to think it is getting keyboard device input, but it came from your program.
If its across a real network, I don't know the best approach. Most such things are simply sluggish and clunky, like most shared desktop software seems to chug up when you type for this very reason.
Well currently in testing I am running both server and client on the same machine but they connect through external IP and the end plan will be that they're (Applications) will be on two different machines. It is just something with the socket but i'm not sure if there is a way i can speed up the socket or store how many times (while held down) VK_BACK is sent and then individually send \b for each of those.
I am not sure. Sockets can send megabytes in fractions of a second these days, but they are terribad at sending 1 byte at a time. They were not really designed for this. If you can afford to buffer up keystrokes and send maybe 2-3, maybe even 5 times a second instead of mega spam, it might perform much better. It will look a little off no matter what you do.. spam will slow up and act weird, buffering prevents seeing it on the remote for a bit and has some lag where you type
abcdefg
and see
abc .. nothing, nothing, nothing, then..
abcdefg all at once..
UDP might do a little better than TCP for this, at the risk of losing some keystrokes.
Well, I considered UDP, but I ruled it out exactly for that reason. As you can tell I am attempting to make this as accurate as possible. If I gather multiple backspaces at once to send all of them a few seconds later I fear that when met with a fast typer the program will remove the wrong things. If the user types another 4-5 chars or so seconds after pressed backspace it will then remove those four or five chars rather than the original ones they were intended to remove.
You might be amazed at what 5 - 10 hz buffered instead of get-it-spam-it will do -- try it, its not much code over what you have. 5x a sec would buffer 2-3 for most typists, not much, but enough?
Also, many networked programs do exactly that (aggravate the user with delays). Users are unfortunately used to it, because I don't think anyone has solved the problem of getting real time performance over a remote session yet.