kind of works? reading multiple mice: any c programmers want to look at this?

[madscijr]

@madscijr

It isn't that it is impossible to use WindowHandle as our HWND.... It's just that we will most certainly have to register our window to accept messages and that we absolutely must use a callback function. Besides, oftentimes you don't even need to pass in the window's handle because a default of NULL/zero just tells it to use the calling window.

That is encouraging. 
I started trying to stop it from opening the white window, and get the callback to operate on the main window. Not at the PC now to recall exactly what I did, but I must have done it wrong, so that's when I started reading up on the API functions... 
If you think you know how to get the callback to operate on the main window, let me know, otherwise I'll keep researching & experimenting.
Thanks!

[SpriggsySpriggs]

I do know how to make a callback work with the default QB64 window as it is something I have done before in the past with my TaskDialog stuff. I'll have to take some time and look at this again and get back with you. Sorry for not being as active as I could be. I've been sick these past few days. One thing we have to consider, though, with using the QB64 window, is the performance impact. We can't (shouldn't) use _LIMIT to reduce the loop speed so it has to run at full speed. Since it is an OpenGL window, there's all that memory being used at a full speed loop. With Win32, it's designed for that sort of thing. I'll get back to ya.

[SpriggsySpriggs]

I do believe I've spoken too soon. TaskDialogs use a different callback setup than this rawmouse stuff. However, I *might* have a solution.

[madscijr]

I do know how to make a callback work with the default QB64 window as it is something I have done before in the past with my TaskDialog stuff. I'll have to take some time and look at this again and get back with you.

Sure, whenever you can!

Sorry for not being as active as I could be. I've been sick these past few days.

No worries Spriggsy. It's not like you're getting paid for this, LoL.
I very much appreciate all the time, knowledge, effort and help you have so generously donated towards this and all my other crazy questions! You take care of yourself first and foremost. I can keep messing with this thing and if & when you get time to look at it some more great.

One thing we have to consider, though, with using the QB64 window, is the performance impact. We can't (shouldn't) use _LIMIT to reduce the loop speed so it has to run at full speed. Since it is an OpenGL window, there's all that memory being used at a full speed loop. With Win32, it's designed for that sort of thing. I'll get back to ya.

Ah, interesting. I use _LIMIT to control the speed of the game (FPS) so I guess we'd need to find some other way to do that. But I can cross that bridge when I come to it!

I do believe I've spoken too soon. TaskDialogs use a different callback setup than this rawmouse stuff. However, I *might* have a solution.

Wow, OK. Whenever you get around to it, do let us know!

Thanks again Spriggsy, you're the man on APIs!

[SpriggsySpriggs]

I don't want to destroy your hopes and dreams but it might be impossible with QB64's window just for the reason that the window is already registered. However, if I can unregister the window and then re-register it..... maybe it would work? I'll try it out. It's going to be a complicated mess no matter how we go about it, unfortunately.

[madscijr]

I don't want to destroy your hopes and dreams but it might be impossible with QB64's window just for the reason that the window is already registered. However, if I can unregister the window and then re-register it..... maybe it would work? I'll try it out. It's going to be a complicated mess no matter how we go about it, unfortunately.

Ok... Well it's worth a try! 

The other approach I was originally planning to try (when it was 100% C code) was to create a separate executable that read the mouse coordinates, relative to the Windows desktop and not the QB64 Window. The QB64 program would call it using your pipecom method, sending in a command line parameter to specify which mouse to return coordinates for (sending in none, it would simply return the count of raw input mouse devices detected), and it would return the x/y coordinates & mouse button status for the specified mouse, in a string formatted something like 
{x},{y},{button1},{button2},{button3},{scrollwheel}
as either absolute position or dx,dy, whichever works. 

So along those lines, how about getting RawInput to return the mouse position relative to the Windows desktop, rather than the QB64 program window? 

Alternately, what if the mouse code creates a Window that it uses to get mouse input, but it's an invisible window (maybe just don't paint it?) maximized to take up the full desktop? 

Then inside the event, it calls the regular QB64 routines that process the mouse input, read keyboard input, and update QB64's screen (which is visible since the mouse window is transparent)? 

My gut tells me there has to be a way to make this work!

[SpriggsySpriggs]

We can get the number of raw input devices without having any extra windows. That InitRawInput function can be used without the C stuff. And we couldn't really use pipecom for the idea you have.... However, we could use my code that allows two programs to talk to one another. But it won't really work since that raw stuff only keeps track of the mouse when in the boundaries of the window that is tracking that message. Also, even if we made a maximized window that was clear, any interaction with another window will pause this transfer of information as it will no longer be tracking the mouse. The window has to be the window that is currently in focus in order to receive this. Brainstorming....brainstorming....brainstorming.....

[Pete]

Interesting concept. I know game consoles are set up this way. So instead of making a chess game that requires either a shared mouse, or two computers connected by a network routine, I'm assuming if this is doable, a single computer could be used with two mouse controllers attached.

Pete

[SpriggsySpriggs]

LOL! @madscijr , I just saw this https://www.asawicki.info/news_1533_hand..._raw_input
Didn't realize you've been at this for such a long time.

[madscijr]

Interesting concept. I know game consoles are set up this way. So instead of making a chess game that requires either a shared mouse, or two computers connected by a network routine, I'm assuming if this is doable, a single computer could be used with two mouse controllers attached.

Pete

Not just two, as many mice as there are USB ports (theoretically!)
And not just mice, but keyboards as well. 
See earlier in this thread, we got a crude example working, albeit displaying in a very rudimentary way using DrawText. 
The challenge now is to figure out how to make it work using the main QB64 program window, so we can use all the regular QB64 graphics commands to control what's displayed on screen.