_MOUSEHIDE / _MOUSESHOW - Printable Version +- QB64 Phoenix Edition (https://staging.qb64phoenix.com) +-- Forum: Chatting and Socializing (https://staging.qb64phoenix.com/forumdisplay.php?fid=11) +--- Forum: General Discussion (https://staging.qb64phoenix.com/forumdisplay.php?fid=2) +--- Thread: _MOUSEHIDE / _MOUSESHOW (/showthread.php?tid=1189) |
_MOUSEHIDE / _MOUSESHOW - Pete - 11-25-2022 Here are some interesting observations about _MOUSEHIDE and _MOUSESHOW See the remark statements at the top of the code. Code: (Select All) ' _MOUSEHIDE _MOUSE SHOW DEMO So curious that if you continuously move the mouse with no button held, the pointer hides on the red screen and shows on the white, as expected, but... if you initiate and hold any mouse button down WHILE ON THE WHITE SCREEN, it shows up all the time, even on the red screen. Personally, I wish it would continue to show and hide regardless of mouse button status, but unless this is a "glitch" I wonder what was the thought process to have it coded this way? Pete RE: _MOUSEHIDE / _MOUSESHOW - mnrvovrfc - 11-25-2022 Those statements seem to have been provided "just in case", and otherwise shouldn't be needed. I don't remember well but programming MS-DOS and early Windows applications required the mouse cursor drawn, or it came from a driver, which made it a necessity to "hide" the cursor temporarily, draw all or part of the screen and then "show" the cursor again. It's because a driver cannot know what another program is doing with the screen. Also if the mouse cursor has to be drawn like a simple circle or rectangle in somebody's newb program, it definitely has to be managed "manually". These days, however, it's managed gracefully by the operating system. There's almost no worry of the cursor leaving trails somewhere... Sometimes this combination could be dangerous. I had some programs disappearing the mouse cursor and unable to get it back which forced me to quit on it, or even log out the user session. Thankfully on Linux the mouse cursor seems to be managed by the desktop environment such as KDE Plasma. It should be alike on Macintosh or Windows. RE: _MOUSEHIDE / _MOUSESHOW - gaslouk - 11-26-2022 Hi This only happens when the red screen lights up while you have already pressed a mouse button and not when you press a button while the red color is displayed. Gaslouk RE: _MOUSEHIDE / _MOUSESHOW - SMcNeill - 11-26-2022 Not a "glitch". This is actual OS intended behavior. Imagine this scenario -- you have a visible mouse cursor. You're holding it down and drawing a pretty little line towards the latest country that annoyed you and you want to nuke... ...suddenly...POOF!! Your mouse pointer is gone!!... ...OH NO!! You just nuked your girlfriend's house by accident!! AHHHHHHHHHHHH!!! The OS can't know how important what you're doing is, nor what your threshold level is for things disrupting your work flow... If you're interacting with the mouse, via a button down or other such "major event", the OS isn't going to touch those mouse settings with a ten-foot pole! Think of it much like trying to delete a file and getting the message, "You can't do that Pete. That file's open in another program!" New processes generally don't engage with resources or their settings if they're in use by another process. (Unless you've jumped through hoops and specifically marked them as multi-process enabled, which I don't even know if that's possible with the mouse.) RE: _MOUSEHIDE / _MOUSESHOW - Pete - 11-26-2022 That's what I've been finding from doing some experimenting and research. What I still haven't figured out is how Windows sticks that damn mouse pointer to one spot, regardless of how fast you move the window. I put this little demo together with a loop event to exaggerate how the mouse cursor races the window. Start the drag and then swirl the mouse around in a big circle and watch the window chase the mouse... Code: (Select All) DIM WinMse AS POINTAPI So what I was aiming to do before was hide the mouse during any off the drag point phase, but that is not possible since a button held negates the _MOUSEHIDE command. So still looking for the method that keeps the two married. I even tried the Win32 API MoveWindow approach, but it works the same as _SCREENMOVE. Obviously the mouse pointer has to move off the fixed point a bit to get the new position, but try a drag on a small resized QB64 IDE window and see how much better the pointer stays fixed to the drag point even during very rapid movement. Oh well, in California, life's a beach. Good surf today, sunny and 75. Pete RE: _MOUSEHIDE / _MOUSESHOW - SMcNeill - 11-26-2022 Try this. How's it perform on your machine? Code: (Select All) Screen _NewImage(800, 600, 32) That seems to pretty well stick the mouse to my window, wherever I start dragging it from. RE: _MOUSEHIDE / _MOUSESHOW - Pete - 11-26-2022 In a word, nope. Same results I get when I run mine. Move the mouse quickly and it separates approximately 30 - 40 pixels from the drag point and back. Do exactly the same thing with a Windows app, and it sticks like glue. So if you can't see this much difference on your machine, it's probably a difference in whatever components control speed issues, the processor, video card, whatever. About the only thing I haven't tried replacing to an API method are the _SCREENX and _SCREENY statements, but I really have my doubts that they are slower than whatever API function is used for reporting upper left window coordinates. BTW - The routine I made for reporting the desktop coordinates is... Code: (Select All) DIM Rec AS Rectangle I found it interesting it only reports after you stop dragging your Win around, not during. So Stevie Nicks aside for a moment, I wonder why that is? The same thing happens if you stick _SCREENX and SCREENY in that loop. Maybe it was designed that way by Windows to ignore the changing positions while dragging to increase speed. Certainly not good for collision detection. Help! My IDE window crashed into my browser window and there's BOLD everywhere! Now if you will excuse me, I have to get back to that other Stevie... Kidding aside, and true story, I saw Fleetwood Mac the first time when I was 18. Stevie would change tops on stage, in a somewhat secluded area. Of course I was glad I invested in those premium high powered binoculars, so... Anyway, in later years I told my wife that story and she replied, "When Stevie Nicks sings she bleats like a sheep!" I agreed, and told her that was half the fantasy. Well, we didn't discuss the matter much after that comment, and frankly, I was also glad I invested in that premium pullout living room sofa. Pete RE: _MOUSEHIDE / _MOUSESHOW - mnrvovrfc - 11-26-2022 (11-26-2022, 04:55 PM)Pete Wrote: Now if you will excuse me, I have to get back to that other Stevie... Kidding aside, and true story, I saw Fleetwood Mac the first time when I was 18. Stevie would change tops on stage, in a somewhat secluded area. Of course I was glad I invested in those premium high powered binoculars, so... Anyway, in later years I told my wife that story and she replied, "When Stevie Nicks sings she bleats like a sheep!" I agreed, and told her that was half the fantasy. Well, we didn't discuss the matter much after that comment, and frankly, I was also glad I invested in that premium pullout living room sofa.There's a song by her that I swear she roars like a lioness and I think it's fantastic -- STAND BACK! Otherwise likes electronic music from the mid-1990's... |