12-10-2022, 05:08 PM
>"In addition, I assume if I want mouse-reading ability, I would need to place a sub call in each of the do/loops I have in my program where I want to use said mouse?
Yes, and see comments below for options.
>" And similiar to keyboard input, I would use a select case and check if at this x and y (do I need to track the start x,y and release x,y to ensure I am still in a defined box click area?)
x, y do not need to be "released." If you want to track the previous coordinates, do this..
So whatever action a click caused, it did so at the x and y coordinates. Those coordinates now become oldx and oldy, so if you move the mouse, the routine knows there was a location change.
For sub-routines, you have two choices I'll discuss here for mouse / keyboard setup.
1) Put the whole read mouse and or keyboard routines in one sub-routine.
Advantages: easy to access, debug, and if you put a new routine together, just add the conditions to that one sub
Disadvantages: If your routine gets big and complicated, your one mouse sub-routine could get hard to manage. I have one like that. My solution, because I do like having just one actually combined muse and keyboard routine, is to flag where the need for action is coming from, and then use a SELECT CASE in the mouse/keyboard routine to route to the proper action conditions. YOu may want to do a string flag, instead of a numeric one, as it is easier to debug: myflag$ = "draw-to-screen" rather than myflag% = 1.
2) Put together a single mouse reading sub-program and after each call make a separate set of conditions after that call, to handle what the mouse routine spits back.
Advantages: You can see what to expect everywhere in your program instead of trying to associate what each flag, in the other example, relates to.
Disadvantages: You have to go several places in your code to work on your mouse events.
-------------------------------------------------------
In your psuedo-code, I would put
Together with your mouse actions sub-routine call, if you want to keep it that way. No need to separate them with code in-between.
As far as mixing mouse and keyboard, just make conditions, as needed, if anything conflicts where maybe say when a certain key press is made it takes priority over where the mouse is or any mouse action. A simple example would be if I wanted to hold down the "Z" key to block mouse clicks. I'd have to code the mouse routine to bypass mouse click reading until that key is released.
Anyway, try some stuff and if you get stuck, just post your code and ask for help in the Help ME! sub-forum.
Pete
Yes, and see comments below for options.
>" And similiar to keyboard input, I would use a select case and check if at this x and y (do I need to track the start x,y and release x,y to ensure I am still in a defined box click area?)
x, y do not need to be "released." If you want to track the previous coordinates, do this..
Code: (Select All)
DO
Do
_Limit 30
While _MouseInput: Wend
x = _MouseX
y = _MouseY
' Put other mouse stuff here like reading left and right button status.
lb = _MouseButton(1)
' Put what to do here if a button is pressed.
If lb Then
If oldX <> x And oldY <> y Then Beep ' Only beeps again if mouse is moved to a new location.
oldX = x: oldY = y
End If
Locate 1, 1: Print "x ="; x; "oldx ="; oldX, "y ="; y; "oldy ="; oldY; " ";
LoopSo whatever action a click caused, it did so at the x and y coordinates. Those coordinates now become oldx and oldy, so if you move the mouse, the routine knows there was a location change.
For sub-routines, you have two choices I'll discuss here for mouse / keyboard setup.
1) Put the whole read mouse and or keyboard routines in one sub-routine.
Advantages: easy to access, debug, and if you put a new routine together, just add the conditions to that one sub
Disadvantages: If your routine gets big and complicated, your one mouse sub-routine could get hard to manage. I have one like that. My solution, because I do like having just one actually combined muse and keyboard routine, is to flag where the need for action is coming from, and then use a SELECT CASE in the mouse/keyboard routine to route to the proper action conditions. YOu may want to do a string flag, instead of a numeric one, as it is easier to debug: myflag$ = "draw-to-screen" rather than myflag% = 1.
2) Put together a single mouse reading sub-program and after each call make a separate set of conditions after that call, to handle what the mouse routine spits back.
Advantages: You can see what to expect everywhere in your program instead of trying to associate what each flag, in the other example, relates to.
Disadvantages: You have to go several places in your code to work on your mouse events.
-------------------------------------------------------
In your psuedo-code, I would put
Code: (Select All)
'INSERT MOUSE READING SUB HERETogether with your mouse actions sub-routine call, if you want to keep it that way. No need to separate them with code in-between.
As far as mixing mouse and keyboard, just make conditions, as needed, if anything conflicts where maybe say when a certain key press is made it takes priority over where the mouse is or any mouse action. A simple example would be if I wanted to hold down the "Z" key to block mouse clicks. I'd have to code the mouse routine to bypass mouse click reading until that key is released.
Anyway, try some stuff and if you get stuck, just post your code and ask for help in the Help ME! sub-forum.
Pete
If eggs are brain food, Biden takes his scrambled.