-
Notifications
You must be signed in to change notification settings - Fork 90
Updated to work with .Net 5.0 (Abort is obsolete), Along with other random changes/fixes. #23
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Conversation
…55dac9bdcce4a4ae2ffc3d300f598f8)
Also did fixes. |
… fully fix Thread.abort() being removed as well as making sure there is no stray threads.
WaitWithTimeout milliseconds should be ulong.
@kevinf100 Placing this here since I can't seem to find issues tab on your fork. Running your version, this is working in Windows 11 with 1 oddity I have found: After the first call to SendText(), the next call will be delayed until some physical input is detected (mouse or keyboard). Messages that are queued up execute once per physical input received. For example, if I send 6 messages, the first will send, then if I press a physical key, message 2 will print on key down, message 3 on key up, etc. until all sent messaged are printed. I have KeyboardFilterMode set to All & do not have a MouseFilterMode set at all, as I only want to deal with sending keys in my use case. As I'm writing a remote input application, there may not be any physical input happening on the target machine. |
Using this and not touching mouse or keyboard SendKey works just fine and does all 10 inputs. Edit - Testing a bit more and looking around, I don't see why it would be stalling until a keyboard press. Default detecting is working and changing. |
Thank you for checking. Turns out my application flow was off. I still don't understand what the actual cause of the issue was, but after moving stuff around a bit, everything is working as expected. As this is my first real shot at using C#, no real surprise there. |
My best guess is something to do with a new thread being made when the library loads that just on an infinite loop. Sounds like whenever that loop loops (when a mouse or keyboard input is received.) your whole program resumes. Not sure what is going on, but this uses the lower level Thread and not TaskFactory. |
Also pull request #5
Since abort is no longer in .net 5.0, if we remove the abort the thread throws an exception when the driver is unloaded. Instead we can flag we unloaded and check if we unloaded.
Also I think this exception was unreachable before. If for some reason we leave the while loop we call Unload which than kills itself.