11-17-2025, 01:56 AM
Let me point out some bad logic that you have here.
But, before I do that, let me send you a stream of mouse button information from the mouseinput buffer. Are you ready? My stream of data is going to be the following for mousebutton #1 (the left mouse button):
down
down
down
up
up
down
down
up
down
I have a mouse that's shorting out so it sends these little micropulses all the time....
So you have a DO LOOP:
So this starts running and it DO run WHILE there is MOUSEINPUT in that buffer.
So the loop starts and M1 is....
down
down
down
up
up
down
down
up
down
And then we EXIT the loop.
So at this point M1 reads as being DOWN. It did a whole bunch of assignments and moving memory values back and forth, but at the end of the loop, it tells us the mouse was DOWN.
But let's compare that loop to another one:
WHILE _MOUSEINPUT: WEND
M1 = _MOUSEBUTTON(1)
Well this now runs the buffer and clears it, and then reports the last value of the mouse button to us.
M1 is now... DOWN.
And.... we didn't do a dozen assignments of values back and forth into those variables.
The larger the buffer, the longer your loop processing time is going to be as you're reading those values and then assigning them over and over and over and over and over and over and.... just rewriting the hell out of that one variable.
Why not just run the routine and clear the buffer and then take the value afterwards??
As a logic exercise, *YOU* explain to all the rest of us how the original code would be *any* better than just taking the value at the end of that loop. Run it through your mind however you want. View it from every angle. And then explain WHY you think that you need to get those values *inside* that WHILE loop and not after it's ran and did its thing?
But, before I do that, let me send you a stream of mouse button information from the mouseinput buffer. Are you ready? My stream of data is going to be the following for mousebutton #1 (the left mouse button):
down
down
down
up
up
down
down
up
down
I have a mouse that's shorting out so it sends these little micropulses all the time....
So you have a DO LOOP:
Code: (Select All)
Sub WaitStopMouseInput
Do While _MouseInput
M1 = _MouseButton(1): M2 = _MouseButton(2): M3 = _MouseButton(3)
Loop ' loop to clean mouse input buffer
End Sub
So this starts running and it DO run WHILE there is MOUSEINPUT in that buffer.
So the loop starts and M1 is....
down
down
down
up
up
down
down
up
down
And then we EXIT the loop.
So at this point M1 reads as being DOWN. It did a whole bunch of assignments and moving memory values back and forth, but at the end of the loop, it tells us the mouse was DOWN.
But let's compare that loop to another one:
WHILE _MOUSEINPUT: WEND
M1 = _MOUSEBUTTON(1)
Well this now runs the buffer and clears it, and then reports the last value of the mouse button to us.
M1 is now... DOWN.
And.... we didn't do a dozen assignments of values back and forth into those variables.
The larger the buffer, the longer your loop processing time is going to be as you're reading those values and then assigning them over and over and over and over and over and over and.... just rewriting the hell out of that one variable.
Why not just run the routine and clear the buffer and then take the value afterwards??
As a logic exercise, *YOU* explain to all the rest of us how the original code would be *any* better than just taking the value at the end of that loop. Run it through your mind however you want. View it from every angle. And then explain WHY you think that you need to get those values *inside* that WHILE loop and not after it's ran and did its thing?