problem with the mouse

[krovit]

Good morning / good evening to all

Can someone explain the mouse behavior?

At every pressure of CTRL+a (but also any other combination or key) the cursor, instead of staying still where it is, moves on the X and Y axes (mostly upwards).

Why? And how to avoid this?

Thank You...

Code: QB64: [Select]

1. SCREEN _newIMAGE (800,600,32)
2.  
3. do
4.  
5.         j$=inkey$
6.  
7.         while _mouseinput : wend
8.  
9.         if j$=chr$(1) then  ' CTRL+a
10.                 _SCREENCLICK _screenX + _mousex ,  _screenY + _mousey
11.         end if
12.  
13.         locate 10,1: print _mousex , _mousey
14.  
15. loop until j$=chr$(27)
16.  

[Richard Frost]

You're not taking the title bar into account.   I've simplified your code a little - press ANY key.
Why the x correction of 4 is required to keep the mouse stationary I don't understand.

Code: QB64: [Select]

1. Screen _NewImage(800, 600, 32)
2. Do: _Limit 10
3.     i$ = InKey$
4.     While _MouseInput: Wend
5.     If Len(i$) Then _ScreenClick _ScreenX + _MouseX + 4, _ScreenY + _MouseY + 27
6.     Locate 10, 10: Print Using "##### "; _MouseX; _MouseY
7. Loop Until i$ = Chr$(27)
8.  

[SMcNeill]

The 4 might be the window border throwing numbers off.  At least, that's my guess.

[krovit]

Thank you Richard, very kind

I didn't expect to have to insert a corrector on the X / Y axes, also because the mouse range doesn't take into account the title bar and the window borders.

It also seemed that correcting the position was a clumsy fallback: you should know the reason for each behavior before "correcting" an unexpected result.

Probably if windows were set in some particular way also the corrector should be varied (maybe he means this SMcNell).  For example, in my case, I have to put "26" and not "27".

However I believe that the argument has been useful to all :)

[SMcNeill]

https://qb64forum.alephc.xyz/index.php?topic=1020.msg138098#msg138098

You can get your heights/widths from the routines in the topic above.

 QB64: [Select]
DECLARE LIBRARY
    FUNCTION glutGet& (BYVAL what&)
END DECLARE
 
_SCREENMOVE 200, 200 'We moved our screen to 200,200 so we know these values are correct
BorderWidth = glutGet(506)
TitleBarHeight = glutGet(507)
ActualScreenX = glutGet(100)
ActualScreenY = glutGet(101)
 
PRINT "Actual Top Left of screen is at ("; _SCREENX; ","; _SCREENY; ")"
PRINT "The border is "; BorderWidth; "pixels"
PRINT "And the title bar is"; TitleBarHeight; " pixels"
PRINT "So your actual display starts at ("; ActualScreenX; ","; ActualScreenY; ")"

[krovit]

Thanks SMcNelly, to avoid surprises so it's even better!

The problem is not yet completely solved but I believe that the road to a solution passes from here

[bplus]

Funny!

Code: QB64: [Select]

1. Screen _NewImage(800, 600, 32)
2. Do
3.     Cls
4.     i$ = InKey$
5.     If Len(i$) Then _ScreenClick _ScreenX + 50, _ScreenY + 10
6.     While _MouseInput: Wend
7.     Print _MouseX; _MouseY
8.     _Display
9.     _Limit 10
10. Loop Until i$ = Chr$(27)
11.  
12.  

Now try this!

Code: QB64: [Select]

1. Screen _NewImage(800, 600, 32)
2. Do
3.     Cls
4.     i$ = InKey$
5.     If Len(i$) Then _ScreenClick _ScreenX + 20, _ScreenY + 10
6.     While _MouseInput: Wend
7.     Print _MouseX; _MouseY
8.     _Display
9.     _Limit 10
10. Loop Until i$ = Chr$(27)
11.  

No popup window like when you click a regular app there (on app icon) just closes down. (Same with .exe)

[krovit]

Yes bplus... what happens is understandable but it seems a little strange behavior