Thanks Steve.
Why the "_delay"? (The command. Not the speed at which you responded. lol)
Just curious...
J
To prevent any race conditions from glitching up the command when you first start up a QB64 SCREEN. Take a moment to think of how QB64 starts...
*ALL* QB64 programs start in a default SCREEN 0 window.
Windows requires a few cycles to register that default SCREEN 0 window handle, and then give it to us so we can use it.
_SCREENMOVE works off that handle...
But what if we call _SCREENMOVE before we get that handle? (Spoiler: NOTHING happens. We try to move a null-handle window, so do nothing at all...)
Now, add in a screen change with: SCREEN. _NEWIMAGE(640, 480, 32)
Once again, windows will update handles and such, and send us back that information.
But what if you call _SCREENMOVE before the new handle comes back? (Spoiler: You move that original SCREEN 0 window, miliseconds before it closes forever.)
To prevent these issues, it’s a good idea to implement a slight _DELAY after swapping SCREEN modes, and before moving that screen.
Once the screen is initialized, you can move it all you want, with no problems or worries, but if you’re going to use a SCREEN change, with _SCREENMOVE after, *always* add a miniscule delay to allow windows time to make and register your handles and such, before using them.
