![]() |
APIs from QB64PE and parameters defined As Any and unions of types ? - Printable Version +- QB64 Phoenix Edition (https://qb64phoenix.com/forum) +-- Forum: QB64 Rising (https://qb64phoenix.com/forum/forumdisplay.php?fid=1) +--- Forum: Code and Stuff (https://qb64phoenix.com/forum/forumdisplay.php?fid=3) +---- Forum: Help Me! (https://qb64phoenix.com/forum/forumdisplay.php?fid=10) +---- Thread: APIs from QB64PE and parameters defined As Any and unions of types ? (/showthread.php?tid=2755) |
RE: APIs from QB64PE and parameters defined As Any and unions of types ? - madscijr - 06-06-2024 (06-06-2024, 05:48 PM)SpriggsySpriggs Wrote: I hate to say it but I am lost looking at your code :/ Thanks for this, it at least gives me something to go on. BTW The reason I am attempting to read the keyboard with Raw Input API is that the built-in QB64PE methods for reading the keyboard aren't working for the solution. If you recall, the RawInput program is event driven and uses its own hwnd handle, and regular QB64PE graphics and text display commands don't work. So my solution was to put the user input (keyboard and mouse) in a seperate sub program that is kicked off by the main program. The sub program window sits directly over the main program, and always has the focus (so it can read the mice). The sub program window's alpha transparency is set to 1 (setting it to zero disables focus) which effectively renders it invisible. So it has the focus and reads the mice with the Raw Input API events, and sends the input it detects up to the main program over local TCP/IP. The main program has all the logic and processes the input, outputs the graphics & sound. Because the sub-program is transparent, the main window is what the users see. And because it never has the focus, it can't detect keypresses, the subprogram has to do that. However I have tried reading the keyboard using normal QB64PE commands (_BUTTON, _KEYDOWN, _KEYHIT, inkey$) but they don't seem to work from the subprogram. It's probably due to the same reason that graphics commands don't work - it uses its own window handle. So since it works so well for reading mice and sending the input back via TCP/IP, I figure that's the way to read the keyboard as well! RE: APIs from QB64PE and parameters defined As Any and unions of types ? - SpriggsySpriggs - 06-06-2024 Oh I just had a thought. Since you are calling GetRawInputData with a zero for that pData field, you are grabbing the size that you need for the struct. That's how we figure it out for the keyboards! If the returned dwSize is equal to RAWINPUT containing RAWMOUSE, then you know it should be a mouse call. Therefore, you need to make a second RAWINPUT type, maybe RAWINPUT_K and make that one contain RAWINPUTHEADER and RAWKEYBOARD. Then you'd do the rest the same way except you'd be using the keyboard's type. Maybe something like this: Code: (Select All)
Don't paste that code as-is. It's just an idea for you to expand upon. However, I think it will get you closer. You'll need to do a lot more work but it might be a solution. Maybe. ¯\_(ツ)_/¯ RE: APIs from QB64PE and parameters defined As Any and unions of types ? - madscijr - 06-06-2024 (06-06-2024, 06:51 PM)SpriggsySpriggs Wrote: Oh I just had a thought. Since you are calling GetRawInputData with a zero for that pData field, you are grabbing the size that you need for the struct. That's how we figure it out for the keyboards! If the returned dwSize is equal to RAWINPUT containing RAWMOUSE, then you know it should be a mouse call. Therefore, you need to make a second RAWINPUT type, maybe RAWINPUT_K and make that one contain RAWINPUTHEADER and RAWKEYBOARD. Then you'd do the rest the same way except you'd be using the keyboard's type. Hmm, makes sense, could work? I will look into that when back at my PC. Thank you sir! RE: APIs from QB64PE and parameters defined As Any and unions of types ? - SpriggsySpriggs - 06-06-2024 You're welcome! I hope it works. No guarantees, though.¯\_( ͡° ͜ʖ ͡°)_/¯ |