Is _WINDOWHANDLE working properly?

[SMcNeill]

Yes I'm using the current version of QB64PE, and yes I get the same values running your code as posted (which is using _DELAY).  Here's the output

0
0
800
600
263499      263499

And here's what I get when running that but using _SCREENEXIST instead of _DELAY.

0
0
640
400
460002      460002

So it looks like _WINDOWHANDLE is working either way, but for some reason the API doesn't take it without a delay?  I dunno. It should return 800x600 too but isn't.

- Dav

Your results explain what's happening perfectly, @Dav -- many thanks for those!

_SCREENEXISTS is working 100% as it should be.
_WINDOWHANDLE is working 100% as it should be.

So what's going on to cause the issue here??

Let's run down the process of what's happening step-by-step:
The program starts to run.  *ALL* QB64 programs start out in a 640x400 screen (SCREEN 0 default screen).  
As soon as this SCREEN 0 screen is created, _SCREENEXISTS is going to return a -1 flag.  (After all, the screen now *does* exist.)
_WIDOWHANDLE at this point should also exist.  Your code works without erroring out, so it *IS* indeed giving you the proper window handle.
You then call the command to change screen resolution: Screen _NewImage(800, 600, 32)
It takes a few ticks for the PC to run the image change through its dedicated thread....
While that image change takes place, you make a call to tmp = GetClientRect(_WindowHandle, apirect)
GetClientRect then returns the dimensions of the current screen -- 640 x 400 pixels. Windows hasn't changed the screen and updated its API values yet!



A pause with DO: UNTIL _SCREENEXISTS isn't going to do anything to create a pause for you at this point in your program. After all, as you can see from the very start with that initial window handle, **A** screen already exists! (It's the 640x400 SCREEN 0 that exists on start up, but it does indeed exist!)

Which is why the manual pause after the SCREEN _NEWIMAGE makes certain that everything works as expected. Windows has time to change the screen from the initial 640x400 screen to the newly resized 800x600 screen, and then it returns the proper values and everything works as you expect.

It's not a case of _SCREENEXISTS not working; nor _WINDOWHANDLE not working. It's a simple case of polling the API too quickly after making a call to SCREEN _NEWIMAGE. It's returning values back to you -- it's just returning the OLD values back to you as the system hasn't completed the race condition to change to the new screen and register those new values yet.

If any of that makes any sense.

Anywho... I don't think there's actually any glitch in the commands here. I think it's just a case where the user needs to be certain to give the OS time to complete the _NEWIMAGE screen change, before using external APIs to get values back which reference that screen.