Closed Josh-OG closed 11 months ago
Hi @Josh-OG! Thanks for your feedback and sorry for not seeing this earlier.
While sending Windows Messages to a certain key (Example S) it sometimes keeps any other keys which were held at the time to stay in a held down state.
When you say they stay in a held down state, do you mean that they look like their held down to the target application, or just to the InputHelper library itself? If the former: I've never experienced such and I'm not sure it can be fixed as it might be the application's internal keyboard state that has gotten messed up.
Did you experience the same problem in different applications?
I also noticed when making a call like:
If InputHelper.Keyboard.IsKeyDown(Keys.S) AndAlso InputHelper.Keyboard.IsKeyDown(Keys.LButton) Then InputHelper.WindowMessages.SendKeyPress(Keys.A) End If
it would sometimes randomly move my cursor, it doesn't always happen, just thought i'd point it out in case the issue was unknown.
Does seem strange... Are you sure you're not accidentally moving your physical mouse? (Seeing as you check if the mouse button is down)
How much/how far does it move?
Be aware that multiple, rapidly repeating keyboard/mouse input combined with moving the physical mouse may some times cause the cursor to behave in a twitching manner (jumping from one place to another). So if you are actually accidentally moving the mouse it is not necessarily the library's fault, but merely Windows being unable to properly handle the massive flood of input.
Regarding these two issues the chances are, sadly, actually very small that it is the library causing them, as it is merely a wrapper calling WinAPI functions (and I have strictly verified that everything is done correctly by comparing my library's input to the results of actual input). It sounds more like it is either Windows or the target application being unable to handle the amount of input you send.
Lastly, this part isn't a bug, just a suggestion. Instead of making a 4.x and a 3.5 version you could just create the .Clear StringBuilder extension in a module which would be compatible with both versions.
Thanks for the suggestion, but unfortunately the separate .NET 3.5 version was made to be able to compile a DLL in Visual Studio 2010 and above that could be used by Visual Studio 2008 and below. The raw source code doesn't compile in VS 2008 or older so I had to make a completely separate project that outputs a .NET 3.5 DLL (which can then be referenced by a VS 2008 project).
@Josh-OG by the way, have you tried sending KeyUp
yourself after a small delay and seen if that fixes any of your issues?
For instance:
InputHelper.WindowMessages.SendKey(Keys.A, True) 'True = KeyDown
System.Threading.Thread.Sleep(1) 'Small delay.
InputHelper.WindowMessages.SendKey(Keys.A, False) 'False = KeyUp
(same goes for the S
key)
Closed due to not being able to reproduce and no further feedback.
While sending Windows Messages to a certain key (Example S) it sometimes keeps any other keys which were held at the time to stay in a held down state.
I also noticed when making a call like:
If InputHelper.Keyboard.IsKeyDown(Keys.S) AndAlso InputHelper.Keyboard.IsKeyDown(Keys.LButton) Then InputHelper.WindowMessages.SendKeyPress(Keys.A) End If
it would sometimes randomly move my cursor, it doesn't always happen, just thought i'd point it out in case the issue was unknown. (The two issues above happened in the 3.5 version and 4.0)Lastly, this part isn't a bug, just a suggestion. Instead of making a 4.x and a 3.5 version you could just create the .Clear StringBuilder extension in a module which would be compatible with both versions. Example:
Imports System.Runtime.CompilerServices Imports System.Text Module Extensions <Extension()> Public Sub Clear(value As StringBuilder) value.Length = 0 value.Capacity = 0 End Sub End Module