Text Only | Text with Attachments

QB64.org Forum

Active Forums => QB64 Discussion => Topic started by: krovit on February 08, 2020, 04:32:36 am

Title: Mouse question
Post by: krovit on February 08, 2020, 04:32:36 am
I'm going crazy!

I thought I had solved this question long, long ago and instead... no.
I searched the forum and saw many examples but still have problems.

Code: QB64: [Select]
  1. i=0    
  4.         if _MOUSEBUTTON(1) = -1 or _MOUSEBUTTON(2) = -1 or _MOUSEBUTTON(3) = -1 then i = 1
  5.    LOOP
  6. loop until inkey$ <> "" or i = 1

The code is easy to understand and works in all cases except one.

It does not work when you get to that point after clicking with the mouse, for example on a menu item.
Evidently the mouse buffer is not empty and by entering the do-loop it immediately passes over.

With the following code I think it is possible to clear the mouse buffer:

Code: QB64: [Select]
  2.     _LIMIT 60
  3.     x = _DEVICEINPUT(2)
  4.     WHILE _DEVICEINPUT(2): WEND 'clear the mouse buffer
  6.  

How to combine the two codes to get the following?
Exit the loop when:
1) having pressed any key
2) clicking on any mouse button

The problem (which is mine: I can't write the code!) occurs ONLY, as I said, when the mouse buffer is not empty.

The error is certainly subtle and small ... that's why it is difficult to find it. Will you help me please?








Title: Re: Mouse question
Post by: krovit on February 08, 2020, 06:43:48 am
Frankly, it does not seem to me an elegant solution, much less brilliant.
So it seems to work but I'm sure there is a better solution.

Well:

Code: QB64: [Select]
  1. i = 0
  3.    x = _DEVICEINPUT(2)
  4.    if _mouseinput = -1 then i = i +1
  5. LOOP UNTIL INKEY$ <>"" or (i > 5 and (_buttonchange(1)=-1 or _buttonchange(2)=-1 or _buttonchange(3)=-1))
  6.  


___

Advice (that you may already know): try a code 10 times. if it doesn't work, get up and go for a ride, maybe outdoors. then come back and try again...
I fall every time: before getting up I try 35,000 times and for many hours... even days!

Title: Re: Mouse question
Post by: OldMoses on February 08, 2020, 08:56:56 am
Not sure if I'm understanding the problem completely here, just throwing this out for your consideration.

When I'm getting a mouse button input, I add the following code after I've gotten the result I want in order to stop accidental "click through" to other procedures that might read remnant clicks in the buffer.

While the code is specifically for mousebutton 1, it gives the basic idea.

Code: QB64: [Select]
  2.         WHILE _MOUSEINPUT: WEND
  3.     LOOP
  4.  

edit: added back the underscores for those not using $NOPREFIX
Title: Re: Mouse question
Post by: Pete on February 08, 2020, 11:49:49 am
I mean in its simplest bare bones form...

Code: QB64: [Select]
  2.     _LIMIT 60
  3.     selkey$ = INKEY$
  4.     IF LEN(selkey$) THEN EXIT DO
  8. PRINT "Button or key press detected. Press any key to test again..."
  10. b$ = INKEY$ ' Clear keyboard buffer because RUN is buggy and doesn't do it!!!
  12.  

And as a continuous test...

Code: QB64: [Select]
  2.     DO
  3.         _LIMIT 60
  4.         selkey$ = INKEY$
  5.         IF LEN(selkey$) THEN EXIT DO
  6.         WHILE _MOUSEINPUT: WEND
  8.     LOOP
  9.     PRINT "Button or key press detected."
  10.     IF CSRLIN > 23 THEN CLS

You could also define the mouse actions to not execute until the buttons were released or execute when pressed, but not execute again until released Those "features" would require additional internal LOOPs.

Pete

Title: Re: Mouse question
Post by: bplus on February 08, 2020, 12:00:52 pm
Quote
It does not work when you get to that point after clicking with the mouse, for example on a menu item.
Evidently the mouse buffer is not empty and by entering the do-loop it immediately passes over.

Here is Steve's oldMouse trick that after responding to a _MOUSEBUTTON waits for a release of that button before responding to a (new) click:

Demo menu in screen 0:
Code: QB64: [Select]
  2.     CLS
  3.     PRINT "Press menu # key or click menu item:"
  4.     FOR m = 1 TO 8
  5.         ms$ = _TRIM$(STR$(m))
  6.         PRINT ms$; ") Menu item "; ms$
  7.     NEXT
  8.     PRINT "9) Quit this demo"
  11.     mx = _MOUSEX: my = _MOUSEY
  12.     k$ = INKEY$
  13.     PRINT
  14.     PRINT "INKEY$:"; k$; "   _MOUSEBUTTON(X) pressed "; mb; "  Current _MOUSEX"; mx; "  Current _MOUSEY"; my
  15.     PRINT
  16.     IF mb AND oldMouse = 0 OR LEN(k$) THEN
  17.         FOR m = 1 TO 9
  18.             IF mb AND my = m + 1 OR k$ = _TRIM$(STR$(m)) THEN 'for screen 0 or default my = line number
  19.                 PRINT "You selected menu"; m: _DELAY 2
  20.                 IF m = 9 THEN SYSTEM
  21.             END IF
  22.         NEXT
  23.     END IF
  24.  
  25.  
  26.  
  27.     oldMouse = mb ' <<<<<<<<<<<<  comment on and off to see difference when hold mouse button down and go up and down menu
  28.     '               oldMouse will wait until you release mousebutton before accepting another menu selection
  29.  
  30.  
  31.     _LIMIT 60
  33.  
  34.  
Title: Re: Mouse question
Post by: Pete on February 08, 2020, 12:35:14 pm
Yep, it all depends on what you need to do. For instance, some programs require timers to detect double clicks. Some can have loops to wait for press release combos, but like Mark's example using Steve's code, you might need that flow-through ability, which allows for other events to not be held up by a prolonged mouse action. Drag and drop, or drag to highlight are other mouse coding events you could add, if needed. All of these require the user think through what is required first, and then build an engine to support those requirements. Hell, I should talk. I've done all of the above and got there mostly by run and gun. :D

Pete
Title: Re: Mouse question
Post by: krovit on February 11, 2020, 07:27:21 am
Thank you for your contributions!

This 3D has become a useful catalog of solutions to manage the mouse and keyboard.

I have not verified all the examples but I can confirm that when the mouse buffer is not null they do NOT work as we would expect.  I confirm that the solution I inserted in any case.

Title: Re: Mouse question
Post by: TempodiBasic on February 12, 2020, 08:16:27 pm
Strange!

It doesn't clear the buffer of mouse! The oldX and x are the same, and so for OldY and y.

Code: QB64: [Select]
  1. SCREEN _NEWIMAGE(600, 800, 32)
  4.         Omx = _MOUSEX
  5.         Omy = _MOUSEY
  6.         DO WHILE _MOUSEINPUT: LOOP ' clear mouse buffer or no?
  7.         LOCATE 10, 1: PRINT _MOUSEX, _MOUSEY
  8.         LOCATE 11, 1: PRINT Omx, Omy
  9.     END IF
  11.  
Title: Re: Mouse question
Post by: TempodiBasic on February 13, 2020, 02:19:20 pm
going deeper!
it seems that the _mouseinput event is so much in a second that we must stop the time for a bit to see that just for that so little bit mouse buffer is empty

Code: QB64: [Select]
  1. SCREEN _NEWIMAGE(600, 800, 32)
  4.         Omx = _MOUSEX
  5.         Omy = _MOUSEY
  6.         DO WHILE _MOUSEINPUT
  7.  
  8.         LOOP ' clear mouse buffer
  9.         LOCATE 10, 1: PRINT _MOUSEX, _MOUSEY
  10.         LOCATE 11, 1: PRINT Omx, Omy
  11.         IF NOT _MOUSEX = Omx THEN _DELAY .5
  12.         IF NOT _MOUSEY = Omy THEN _DELAY .5
  13.     END IF
so it seems that the solution is to put a _delay into the clear buffer loop!

Title: Re: Mouse question
Post by: SMcNeill on February 13, 2020, 02:54:03 pm
Why does it seem everyone always makes mouse input so complicated?

Code: QB64: [Select]
  2.     WHILE _MOUSEINPUT: WEND ‘Update the mouse
  3.     MBIND = _MOUSEBUTTON(1) ‘Mouse Button Is Now Down
  4.     IF MBWU AND MBIND THEN ‘If Mouse Button Was Up AND Mouse Button Is Now Down
  5.         PRINT “You clicked the button!”
  6.     END IF
  7.     MBWU = NOT MBIND ‘Mouse Button Was Up
  8.     _LIMIT 30
  10.  

Mouse input, by itself, is a very simple thing.  Basically, all the commands tell us is:  Where’s the cursor and which buttons are up and down.

It’s up to the programmer to setermine what their program actually needs to function properly. 

In a game, you might just want to know if the button is up or down to shoot at enemies.

You might need a “click event” for a button — so you need to decide exactly what qualifies as a click event in your program.  My example above may not suit your needs, if you need a click to be counted as an “UP-DOWN-UP” event.  All my little demo above worries about is “was it up, and is it now down?; it doesn’t track “is it now up again?”

Decide what you need for your mouse events and then code for them. 

Click — Up, Down.
Double Click — Click + Click within X miliseconds.
Down and Hold — Down for X+ miliseconds
Hover — Up for X seconds without mouse x/y changing

And so on...
Title: Re: Mouse question
Post by: TempodiBasic on February 13, 2020, 04:07:03 pm
Thanks Steve
you're right!
For my problem I have had searched where to put loop washing out buffer of mouse and how to solve the bad passage through it!
My problem (now solved thanks to your encouragement) is a simple issue to put (more bad app design than bad coding) in the same place two different buttons that are activated in different but sequential events... so when the user did click on the first button it activated the second button in the same place of the first and the program activated also the second button as clicked!
A bad event cascade! :-)
Text Only | Text with Attachments