Is _WINDOWHANDLE working properly?

[Dav]

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

[TerryRitchie]

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.

[SMcNeill]

_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. 

[TerryRitchie]

_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. 

Yeah, I didn't consider the other commands that would be affected.

[Dav]

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

[SpriggsySpriggs]

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.