+- QB64 Phoenix Edition (https://qb64phoenix.com/forum)
+-- Forum: QB64 Rising (https://qb64phoenix.com/forum/forumdisplay.php?fid=1)
+--- Forum: Code and Stuff (https://qb64phoenix.com/forum/forumdisplay.php?fid=3)
+---- Forum: Help Me! (https://qb64phoenix.com/forum/forumdisplay.php?fid=10)
+---- Thread: Is _WINDOWHANDLE working properly? (/showthread.php?tid=1917)
Pages:
1
2
RE: Is _WINDOWHANDLE working properly? - Dav - 08-18-2023
Ah, that makes sense. Thanks for the explanation, Steve. That clears up a puzzle I've had for a while, wondering why I still had to use a _DELAY when playing with some API calls. Also glad to know there's no real bugs in using those keywords.
- Dav
RE: Is _WINDOWHANDLE working properly? - TerryRitchie - 08-18-2023
So perhaps _SCREENEXISTS should be renamed to _PETESCREENEXISTS
Kidding aside, it seems _SCREENEXISTS is really only useful for SCREEN 0 programs then, or perhaps as a self check for the program to see that it's actually running, which doesn't sound useful or for that fact make any sense to me.
Perhaps a better approach would be to have the SCREEN statement not return until the API values have been updated. This forced delay though would likely not be appreciated by many.
RE: Is _WINDOWHANDLE working properly? - SMcNeill - 08-18-2023
_SCREENEXISTS can help catch glitches where you might try and call an API *before* that initial screen is created, but once you have that first screen, it's always going to report a -1 value for you. A delay could be added to _NEWIMAGE or to SCREEN so that anytime the command is called, the program would automatically wait a moment for everything to be properly registered back in the OS, but I really don't think anyone would like that.
OneScreen = _NEWIMAGE(640,480,32)
TwoScreen = _NEWIMAGE(640,480,32)
DO
'draw stuff on OneScreen
SCREEN OneScreen
'copy and draw stuff on TwoScreen
SCREEN TwoScreen
LOOP
Would you *really* want a built in delay in those two SCREEN statements? Those screens already exist. Is there some true need to add that lag into a program?
Same way with the _NEWIMAGE and _COPYIMAGE commands. Would they really need a delay to affect things all the time?
It's really only when you're calling out to API calls that you run into the issue you're seeing here. It's just a basic multi-threading issue at work.
Sometimes, the user just has to be careful of giving things time to run and complete before doing other stuff. Manual pauses/delays are the best way I see to do this, unless someone else has a better working solution.
RE: Is _WINDOWHANDLE working properly? - TerryRitchie - 08-18-2023
(08-18-2023, 03:44 PM)SMcNeill Wrote: _SCREENEXISTS can help catch glitches where you might try and call an API *before* that initial screen is created, but once you have that first screen, it's always going to report a -1 value for you. A delay could be added to _NEWIMAGE or to SCREEN so that anytime the command is called, the program would automatically wait a moment for everything to be properly registered back in the OS, but I really don't think anyone would like that.Yeah, I didn't consider the other commands that would be affected.
OneScreen = _NEWIMAGE(640,480,32)
TwoScreen = _NEWIMAGE(640,480,32)
DO
'draw stuff on OneScreen
SCREEN OneScreen
'copy and draw stuff on TwoScreen
SCREEN TwoScreen
LOOP
Would you *really* want a built in delay in those two SCREEN statements? Those screens already exist. Is there some true need to add that lag into a program?
Same way with the _NEWIMAGE and _COPYIMAGE commands. Would they really need a delay to affect things all the time?
It's really only when you're calling out to API calls that you run into the issue you're seeing here. It's just a basic multi-threading issue at work.
Sometimes, the user just has to be careful of giving things time to run and complete before doing other stuff. Manual pauses/delays are the best way I see to do this, unless someone else has a better working solution.
RE: Is _WINDOWHANDLE working properly? - Dav - 08-18-2023
I'll stick with _DELAY .25 for these cases. The only other work-around I found (works without a delay) is doing _SCREENMOVE _MIDDLE after setting up the screen, but I seldom like the placement _MIDDLE puts my window.
EDIT: By the way, the IDE doesn't catch entering a_SCREENMOVE statement with no parameters.
- Dav
RE: Is _WINDOWHANDLE working properly? - SpriggsySpriggs - 08-18-2023
A delay of 0.25 is good. You might be able to also just pass it 0 instead of WINDOWHANDLE. Some API calls will default to the handle of the calling window when 0 is passed. I can't guarantee that GetClientRect is one of those.