QB64 _Display/_ScreenMove Glitch

[SMcNeill]

Now here's a little oddity which you guys might want to make note of, if you're ever going to write a program which removes the window's title:

Code: QB64: [Select]

1. Screen _NewImage(1280, 720, 32)
2.  
3.  
4. Declare Library
5.     Function GetWindowLongA& (ByVal hWnd As _Offset, Byval nIndex As Long)
6.     Function SetWindowLongA& (ByVal hWnd As _Offset, Byval nIndex As Long, Byval dwNewLong As Long)
7. End Declare
8. a = SetWindowLongA&(_WindowHandle, -16, GetWindowLongA(_WindowHandle, -16) And Not &H00C80000)
9.  
10. Do
11.     k = _KeyHit
12.     If k = 32 Then TRY = Not TRY
13.     If k = 27 Then System
14.     If TRY Then
15.         _Display
16.     Else
17.         _ScreenMove _Middle
18.     End If
19. Loop
20.  

Honestly, I don't have a clue what the heck is going on here!   To start with, we make a screen.... Then we remove the title and border...   So far, so good...

Then we enter the do loop with an initial value of 0 for TRY, so we attempt to _SCREENMOVE _MIDDLE endlessly...

And, at this point, the window then centers itself for a nanosecond or two, only to then pop down to my bottom right corner of my screen where it stays until the next call to _SCREENMOVE _MIDDLE.  Inside the loop, this produces a sickening flicker as the screen jumps back and forth endlessly.

BUT....

Then you hit the SPACE BAR and the value of TRY toggles.  We execute a simple _DISPLAY command...  And NOW our window stays in the center, regardless of if we ever hit the spacebar again, or not.

Without the _DISPLAY, the window loses itself and doesn't know where the heck to pop, going to the bottom corner rather than the center of the screen.

My initial impression is (and this might be completely wrong):

I have a feeling that QB64 (or GLUT) has internal variables which track our various pieces of screen information (x and y position, size, ect..), and this information doesn't update until a call to _DISPLAY is made.  By removing the title bar, we've changed some of the Windows-side value of these things, but not the QB64-side of stuff.  GLUT, or Windows, or whatever has one value for the middle of the screen (as seen by how it first positions itself in the correct position), but our internal variables have a different position (as seen by how it moves to the second position).

All this time, I've been telling folks that there's a race condition in handles going on when a screen is first created, so they need to place a small delay before making a screenmove call; when instead, it might be this issue with variables not updating until _DISPLAY is called.

Note that the following works perfectly and places the screen in the middle of our display as it should:

Code: QB64: [Select]

1. Screen _NewImage(1280, 720, 32)
2.  
3.  
4. Declare Library
5.     Function GetWindowLongA& (ByVal hWnd As _Offset, Byval nIndex As Long)
6.     Function SetWindowLongA& (ByVal hWnd As _Offset, Byval nIndex As Long, Byval dwNewLong As Long)
7. End Declare
8. a = SetWindowLongA&(_WindowHandle, -16, GetWindowLongA(_WindowHandle, -16) And Not &H00C80000)
9.  
10. _Display
11. _ScreenMove _Middle
12.  

Whereas this doesnt:

Code: QB64: [Select]

1. Screen _NewImage(1280, 720, 32)
2.  
3. Declare Library
4.     Function GetWindowLongA& (ByVal hWnd As _Offset, Byval nIndex As Long)
5.     Function SetWindowLongA& (ByVal hWnd As _Offset, Byval nIndex As Long, Byval dwNewLong As Long)
6. End Declare
7. a = SetWindowLongA&(_WindowHandle, -16, GetWindowLongA(_WindowHandle, -16) And Not &H00C80000)
8.  
9. _ScreenMove _Middle
10.  

The  only difference in the two?  The use of _DISPLAY before _SCREENMOVE.  :P

[Dav]

Interesting.  None of those even compile for me on 32-bit.  I'll play around with it some today.

- Dav

[SMcNeill]

Interesting.  None of those even compile for me on 32-bit.  I'll play around with it some today.

- Dav

Windows?  Or your new Linux set up?  Those are Windows-only library calls.  ;)

[Dav]

Win7 32-bit.

- Dav

[SMcNeill]

Try tossing a small _DELAY in there right after the SCREEN _NEWIMAGE call.  See if that fixes the instant crash issue for you.  I'd guess that invalid handle is still at work and causing a seg fault on a slower PC.  Just add that as another glitch for our screens.

[Dav]

_DELAY didn't work, but I did get it working -- had to do DECLARE CUSTOMTYPE LIBRARY instead and it compiled.

Hmm, on my Windows 7 32-bit I didn't get the glitch, all stayed centered for good. Maybe it's a video driver issue?

- Dav

[SMcNeill]

_DELAY didn't work, but I did get it working -- had to do DECLARE CUSTOMTYPE LIBRARY instead and it compiled.

Hmm, on my Windows 7 32-bit I didn't get the glitch, all stayed centered for good. Maybe it's a video driver issue?

- Dav

Now stuff like this leaves me baffled.  When we DECLARE LIBRARY, we don't need to use CUSTOMTYPE or add a library name, if the functions we want to access are already declared somewhere inside QB64.  DECLARE LIBRARY by itself should be more than sufficient for things to work for us...

Yet, it doesn't work for you...

Which leaves the question, "Why the heck not??"

Is 64-bit QB64 referencing the User32 library, while the 32-bit version isn't??  And why the heck does it work for you and yet perform so jaggedly for me??   

The more I learn about this screenmove/no title business, the more questions I have about what the heck it -- and QB64 -- are doing behind the scenes.   

[Dav]

Here's the compile log error I get when it fails (without adding CUSTOMTYPE).

- Dav

In file included from qbx.cpp:2208:
..\\temp\\main.txt: In function 'void QBMAIN(void*)':
..\\temp\\main.txt:6:99: error: invalid conversion from 'int' to 'HWND' {aka 'HWND__*'} [-fpermissive]
 *__SINGLE_A=(  int32  )SetWindowLongA(func__handle(), -16 ,((  int32  )GetWindowLongA(func__handle(), -16 ))&(~( 13107200 )));
                                                                                       ~~~~~~~~~~~~^~
compilation terminated due to -Wfatal-errors.

EDIT: Oh BTW, I'm not using the latest QB64 version on this laptop.  I'll try to compile on my other laptop with the latest QB64 release.

EDIT #2:  Yeah, compile fails on latest QB64 in 32-bit too, unless CUSTOMTYPE added.