Does pretty much the same thing for me when trying to scroll through code in the IDE. 1 or 2 click delay before things start happening, but it also does this in most games I play that make use of the scroll wheel. I always thought that was intended behavior or hardware behavior just in case the user bumped the scroll wheel so they did get constant jittering around.

Good that it's not just me. I've never seen behavior like that in any other game or software. It's a tad annoying in my opinion that the QB64 IDE does this, and also anything compiled with QB64 will do this. The mouse wheel should respond the 1st scroll click you make. It does seem like an internal counter is counting. No matter how slow you click, when that counter counts to 3 it allows clicks in that direction, and resets itself when changing direction.

Devs: Is this intentional? Is this a feature programmed into QB or is this a possible bug?

The mouse wheel doesn't work until at least 3 consecutive clicks up or down has been registered, then it works fine after each click in the same direction. If you change direction, it then takes another 3 clicks in that direction to get it started. If you go back and forth between up and down never clicking more than 2, it'll never register a wheel click. Example, this sequence won't cause any click: go up 2, down 2, up 1, down 1, up 2, down 1, up 2, down 2...this will never scroll the wheel. But as soon as you hit that 3rd click in the same direction it works in that direction every click.

I tried the simplest example in the help, same problem:

It's not my mouse, the scrolling works fine everywhere else in Windows.

Any idea?

I have software I made that I use primarily on my 2nd monitor in full screen. When I click away to my main monitor, my program flickers black for 1/4 of sec, and flickers again when clicking back into it. Any way around this? It's not the end of the world, but it's slightly annoying.

Here's how I declare and render:

Init:

Mainloop:

Any help would be appreciated. Thanks

There's definitely some internal bugs when it comes to those. Before I found out this feature was added, I had several Types for various objects, but any strings were put in separate arrays like this:

'All the following code is just for examples

REDIM SHARED Obj(0 TO n) AS ObjType
REDIM SHARED ObjText(0 TO n) AS STRING

Both arrays always had the same numbers of elements so it was easy to reference the strings for whatever objects I needed. This worked great and was better than trying to use fixed-length strings in Types.

But when I found out about variable-length strings added to Types, I added the strings to my Types like this in order to clean up my code:

Type ObjType
   a as integer
   b as integer
   Text as string
End Type

REDIM SHARED Obj(0 to n) AS ObjType

After I did this, my program became possessed, weird bugs would happen, some that were even different if I ran the program at another time, even though no code changed.
They appear to be related to the internal memory of how QB handles the strings in the Types.
The bugs seems to always happen in places when I would get the Len of the string -> LEN(Obj(id).Text). I checked and the function is returning the correct length in all my tests, so there's something more internal going on. There seems to be memory overlaps, causing random elements and objects to change their behavior because memory locations are being corrupted.

Another thing that might be affecting it is I have several dozens of objects, each being REDIMed _PRESERVEd when they were created/added to the array, maybe that has something to do with it.

So after scratching my head all day looking if it was my own code, I came to the conclusion that it wasn't my code and put my code back to what it was, putting the strings back in separate arrays. After I did that, my program became normal again working perfectly.

Sorry I can't be more specific, the bugs were really random and weird, but I can tell it's some internal memory problem.

Ooh ok I see, there's a buffer. Makes sense now. Thanks

Here's a little demo to show how the _MOUSEINPUT command can be used to your advantage:

Code: QB64: [Select]

1. SCREEN _NEWIMAGE(640, 480, 32)
2. CLS
3. INPUT "Click around on the screen a few times then press ENTER", a$
4. WHILE _MOUSEINPUT
5.     IF _MOUSEBUTTON(1) THEN
6.         LINE -(_MOUSEX, _MOUSEY), _RGB32(255, 255, 255)
7.         clicks = clicks + 1
8.     END IF
9. WEND
10. PRINT "You clicked"; clicks; " times"

Even when the INPUT command has taken over QB64 is monitoring the mouse.

Ok, I understand the advantage now, that is much better.
Edit: Although this does seem strange to me since the program is both in the Input loop and While:Wend loop at the same time? How is this possible? If it's in the documentation please point me to it so I can understand. Thanks

First, Welcome to the Forum :-)

Which "built-in" mouse routines are you referring to? These..

_MOUSEX, _MOUSEY, _MOUSEBUTTON(), _MOUSEINPUT, _MOUSEWHEEL, etc..?

These commands are a god-send compared to what was available back in the QB45 days. Could you provide some code examples of what you are referring to?

Yes, all of those. Maybe I just didn't put too much thought into it. Like this for example:


This will only get you the values when they change, and you can't just print _MouseX etc without using _Mouseinput first.
All the examples in the help for _MouseInput, _MouseButton, etc have all these Do:Loops where it can be a lot simpler. I've used a lot of libraries in the past and none managed mouse inputs this way, they all have simple functions that return the current values when called. Maybe I'm just not used to it. So what's the advantage?