Ongoing issue in the QB64 IDE where item selected is well below mouse pointer

[hanness]

I've always just sort of lived with this but I thought that I would inquire to see if there was any sort of setting somewhere that can affect this.

I notice that in the IDE the item selected or highlighted is well below the position of the mouse pointer. Take a look at the screenshot below. You can clearly see that the mouse pointer is on the line for "Save" but the IDE thinks that I am pointing to "Save As...".

Any kind of setting to tweak this behavior?

  [ You are not allowed to view this attachment ]  

[FellippeHeitor]

Hello. When you're using the default built-in vga font as you are, the render surface needs to be created in multiples of 8 pixels across and 16 pixels down, which is the size of the individual character. When you maximize the window, it will stretch to fit your desktop, regardless, so you get the extra unrendered black void at the top. Your program is still getting mouse coordinates accordingly but it won't really match what you see when it's like this.

My advice is not to maximize the IDE window, but to enlarge it manually, by dragging from the corners until it uses up your whole desktop. Since it will remember that size and position next time you run QB64, it should solve it for you.

[SpriggsySpriggs]

I find that on a 1080p display, an IDE size of 240 x 63 fits rather well. On Windows 11, the taskbar is slightly larger and this issue is not present.

[Pete]

My advice is not to maximize the IDE window, but to enlarge it manually, by dragging from the corners until it uses up your whole desktop. Since it will remember that size and position next time you run QB64, it should solve it for you.

My advice is to do the same thing by clicking the "Maximize" box symbol, in the top left corner of the IDE. Doing it Fell's way works, too, but its a real drag.

Pete

[hanness]

Huh! That was simple solution. Manually sizing the window solved the issue.

I should have pointed out that I am actually currently running Win 11 (hey, we're 5 days from final initial release) so the issue is still present there, but I'm very happy with this solution and clear explanation of what is happening.

Doing some major updates to my 13,000+ lines of code right and have to say that the debug stuff is making me happier than a pig in slop!

Thanks again for help, gentlemen!

[hanness]

Pete, sorry, missed your post initially. Actually, it is when clicking the maximize button that the problem happens. It does not happen when dragging the corners as was suggested.

[SpriggsySpriggs]

@hanness Did you resize your taskbar at all on 11? As soon as I switched to 11, the issue disappeared immediately and I could maximize QB64. What is your resolution?

[Pete]

Pete, sorry, missed your post initially. Actually, it is when clicking the maximize button that the problem happens. It does not happen when dragging the corners as was suggested.

Well how about that! I never use the maximize window "feature" but I just tried opening menus with it, and got the same results, the mouse pointer being off target. In my set up, there is also a small black horizontal void between the menu headers and the the title bar. That is the space the menu items should occupy, but they get pulled down a bit, during th maximizing process. That would be nice if the IDE could be updated, somehow, to correct that error.

What I do to get a bigger IDE is this...

Options > Display > Check Custom Fonts > Uee: c:\windows\fonts\lucon.ttf > Set Row Height (Pixels) to 25

That's not quite "full screen" on my laptop, but it's close.

Pete

[FellippeHeitor]

That would be nice if the IDE could be updated, somehow, to correct that error.

Beyond my abilities. Been looking at the issue with every development cycle. I just don’t know enough of OpenGL for that.

[Pete]

Well, if there is no way to "hijack" the button, as it is part of the OPenGL window rendering, it might be something that the OpenGL folks need to take a look at.. I would think it would affect others who are dependent on OpenGL for window rendering. I suppose the box symbol could be gotten rid of with maybe ~WS_MAXIMIZEBOX. Other than that, there doesn't seem to be much chatter about this situation on the OpenGL forum I looked at.

Pete

[SpriggsySpriggs]

@Pete No, I wouldn't recommend removing the maximize box. Like I was saying, I don't have this issue in Windows 11. Maximize works great.

[FellippeHeitor]

The problem is not that there is a maximize button, the problem is that by maximising the window, the resulting size might not be a multiple of 8 across/16 down, and that affects specifically the IDE in specific resolution scenarios. It's all very specific.

I do want advice on moving the origin of the texture rendering from the bottom-left of the window to the top-left side. All suggestions welcome.

[Pete]

@Pete No, I wouldn't recommend removing the maximize box. Like I was saying, I don't have this issue in Windows 11. Maximize works great.

From what I've read so far, it may be more of a graphics card issue than a specific Windows version issue. Did you fupgrade to Win 11 from 10, and experienced the problem prior to the upgrade?

Pete

[FellippeHeitor]

It's not Windows specific. It'll happen in any OS, provided the window is the "wrong" size, due to the fact that OpenGL's origin point (0,0) is at the bottom left of the window, as opposed to what we're used, top-left.

[SpriggsySpriggs]

The main reason I'm not having the issue in Windows 11 is that the taskbar being larger fixes the offset