Hi vr, This is really excellent. I made the changes that you recommended and now I am capturing mouse events in addition to keyboard events. I have one remaining question. I recall that there was a way to specify that mouse movements would not be captured, but everything else that was mouse-related, in particular mouse clicks, would be captured. I checked https://docs.microsoft.com/en-us/windows/console/setconsolemode but could not find it. I know that programmatically I can filter out mouse movement events, but then there would be a huge amount of CPU time spent in doing so. Is there a value that can be "or"ed or "and"ed to the values already being sent to the mode () method that prevents mouse movement events from being detected? Thanks again for your solution. | [reply] |
I can filter out mouse movement events, but then there would be a huge amount of CPU time spent in doing so.
There wouldn't. To begin with, Input blocks, you don't have to GetEvents at all, nor sleep/usleep. Next, if "event" is generated (or "message" is sent to application) in case of mouse motion, say, 20* times per second until motion ceases, it's "huge" amount of messages for a human, but your computer/CPU would hardly notice it has spent any time doing so and processing these messages per your instructions -- unless you yourself, as programmer, inadvertently put something time consuming/blocking into event loop.
Have a look at e.g. Term::Choose (which works on top of guess-what Perl module when on Windows), where mouse motion is simply discarded ("filtered") every time, if I'm reading the source correctly. Plus, by the way, I was going to suggest it as kind of higher-level/friendlier/cross-platform/feature-rich text-mode UI toolkit instead of you rolling out your own event loop application with Win32::Console.
(*) I'm sorry, I said "20", but can't, off the top of my hat, provide the exact figure (which probably depends on speed/distance) without googling.
| [reply] |
Sounds very reasonable. The reason I had the GetEvents method first before invoking the GetInfo method is that I believed that because GetEvents returned just a single scalar, that checking it first prior to invoking Input would be more efficient than calling Input, which returns an array of values. But after reading your note, I guess that if Input does not have anything to return it does not do all the processing of assigning undefs to all of the fields that it returns.
Thanks for the link to Term::Choose, it looks very interesting.
| [reply] |
This is some great research!
By any chance, would you have insights into how to block-wait for OpenGL (1, it's for current PDL::Graphics::TriD) events? Currently it constantly polls since it's using GLUT's glutMainLoopEvent. My googling didn't reveal a better way that was somewhat compatible with that. Yes, it should get moved off OpenGL 1, but there are other priorities first such as the imminent OpenCV interface, and loop-fusion.
| [reply]
[d/l] |
| [reply] |
