09-18-2022, 07:05 PM
(09-15-2022, 06:30 PM)Pete Wrote: I foresee "racing" issues if you take that approach.
Pete
(09-15-2022, 06:33 PM)Spriggsy Wrote: Yeah, I think it will be quite a problem. Give me a couple of days to see about this way of unregistering the window and then re-registering it with the callback as part of its registration. That may or may not be the solution.
OK, I would like to pursue this route, because think it doesn't make sense for a raw input API to have to require its own Windows infrastructure, if it's really just pulling in data from HIDs. What if the dx and dy (change in mouse coordinates when it's moved) can still be read without needing a Window?
The other route is, if we can't use QB64's window, can we send the window handle to our QB64 graphic output routines, so our QB64 drawing commands can still be used?
Barring that, currently the RawMouse example uses DrawText to output to the screen, what is the Windows API way to simply plot a pixel or draw a rectangle in x color? Or a bitmap? If we can do that, we can turn it into more friendly functions that take the same parameters as the existing QB64 drawing commands, so coding it is simpler.