Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Is _MOUSEMOVEMENTY and _MOUSEMOVEMENTX supposed to act this way?
#9
@bplus

@TerryRitchie

I'm making something where I need the program window minimized and it tracks the mouse position anywhere on the Desktop at the exact coordinates a _SCREENCLICK or SCREENPRINT could be used. Our QB64 _MOUSEY and X functions, of course, only track movement in the QB64 window, not the entire desktop, and no, I don't want to make the QB64 window a desktop overlay. I could, as I could make it perfectly transparent and you'd never even know it was overlying your desktop, but I don't want that. I want the cursor to move about the desktop, the minimized program window to track it, and if I make a click, those coordinates get feed to the _SCREENPRINT command, and at that screen position on some open desktop app the text gets printed.

Now in QB64 the only keywords that track the mouse cursor outside the program window are _MOUSEMOVEMENTY and X. The problem is they apparently, according to Matt, work based on speed and direction, not on absolute pixel location. I get it "relative" but I thought releative movement out would always equal relative movement back, but they don't work that way. So for example, using those keywords to move the pointer and display the difference from the exact upper left corner of the desktop to the middle of the desktop and back will never get you back to 0, 0. Something like 20, -8. Anyway, that's spells fail for using _SCREENCLICK or _SCREENPRINT at specific desktop pixels, so those two QB64 keyword functions are out.

So for now I just created a simple Windows API call that does this for me. I didn't even have to hock my tiara Steve gave me to do it. API Princess my ASCII! I'm the Queen, and Steve knows it!

Pete (Sorry guys, I feel a bit bloated today.) Big Grin
Reply


Messages In This Thread
RE: Is _MOUSEMOVEY and _MOUSEMOVEX supposed to act this way? - by Pete - 11-01-2022, 03:43 PM



Users browsing this thread: 1 Guest(s)