Yeah that's what I basically do. I have a generic timer function I can call with a timeout and an expression or block of code and it will execute. The problem is that even with the timer it doesn't work unless the timer fires long enough in the future - IOW, it's not just about giving up timeslices, but letting VFP actually render the form first and bring it up which of course depend on the hardware it runs on. The jerky effect that produces unfortunately is very unprofessional. BUt better than not setting the focus for dialogs that let you usually just accept values and ENTER to OK and accept.

+++ RIck ---

>We have standardized a .AfterInit() Method which is called fwk-automatically (IIRC now via bindevent, in vfp6 via timer activated in base class .init() to fire after bubbling up from .Init(), but would not bet large sums...) to combat funky behavior. No idea how effective, as I am not too deep in the GUI side of things, that area is typically handled by others unless it is linked to noticable perf issues.
>
>>Interesting. Didn't know that but that might explain why I see some funky behavior when activating forms from ActiveX controls. I've seen major form focus issues where the forms won't come to the front and most importantly not get active focus.
>>
>>I've taken to using timers to do this but it's noticably slow. I've never seen this flash the screen, but there is definite focus flicker as controls get activated AFTER the bloody form has been active for a few milliseconds.
>>
>>This is one of the biggest problems I struggle with with FoxPro UI apps.I see this in West Wind Html Help Builder primarily which has a Web Browser control that contains a rich editor that interacts with the Fox form (and vice versa) and pushes notifications out from there into the UI. The focus issues have been driving me nuts and its the #1 thing that makes this application not feel like a 'real' Windows application.
>>
>>+++ Rick ---
>>
>>>>Are you sure your screen that you are loading is a desktop form? What is actually flashing white? Is it your actual form or something else?
>>>>
>>>>I have many Fox based applications that launch right off without any sort of background flash even in slow load scnearios. If you see something 'flash' most likely you are loading something else first or as others have pointed out you're seeing the desktop flash up briefly. You might want to make sure the right config.fpw that contains the SCREEN=OFF is getting loaded which is the only way you can effectively surpress the VFP startup window in an EXE. If that's not the case you must have something happening that's loading something prior to your main window showing.
>>>
>>>Just remembered one odd scenario which I haven't seen for at least ten years, but which is still possible: the code in the init of something calls a setfocus() to itself or its contained element. That completely thrashes the order of events, the .show() and .activate fire before the form is completely built, and one may see flashes and other weird effects. I guess it was a solution for some bug which was probably fixed in 6.2 or some such version - and we know the workaround code will outlive us :).
>>>
>>>May be worth checking.