That's not quite my scenario - in my case I have an activeX control (an editor basically) that opens new forms (no activeX control). The forms often don't activate and focus definitely doesn't get set. Under normal circumstances you can use the Activate() event to handle setting focus (along with lFirstLoad flag), but for ActiveX loaded calls that doesn't work.

The only thing I've found that works is using a timer and delaying long enough that the form becomes actually visible, THEN Activting again and then setting focus. It's a bunch of overhead to make this happen.

I use a generic timer function that does this:

EvalTimer("this.State.Focus()",700,1,0,thisform.txtFirstControl)

This basically creates a time, fires it in 700 ms and sets the control as the state.

It works but it's a) very ugly code, b) flashes. Getting the timing right is difficult too - it still fails occasionally even with longer timouts. The reason for all this presumably is that ActiveX controls are not properly giving up focus, unless whatever you're setting focus too is fully instantiated, visible and UI active according to Windows. I wish there was an easier more generic way.

+++ Rick ---

>Yes, the ActiveX fires before everything else, and will actually replace the form object as THISFORM in many situations (maybe all, haven't tested).
>
>What Frank Camp devised was a shape control which only after it is instantiated then instantiates the ActiveX control.
>
>Here's the code popped from the class browser.
>
>

>**************************************************
>*-- Class:        shpaddactivex (c:\vpme9apps\next\scaledsardine\versionb\nnx\classes\proctrls.vcx)
>*-- ParentClass:  shape
>*-- BaseClass:    shape
>*-- Time Stamp:   08/27/02 10:06:05 AM
>*
>#INCLUDE "c:\vpme9apps\next\scaledsardine\versionb\nnx\classes\propromain.h"
>*
>DEFINE CLASS shpaddactivex AS shape
>
>
>	*-- Class to be instantiated
>	cclass = .F.
>	*-- Class Library of class to be instantiated
>	cclasslib = .F.
>	*-- Name of the control when instantiated
>	ccontrolname = .F.
>	*-- Pathed reference to parent; if empty, defaults to thisform
>	cparent = .F.
>	Height = 17
>	Name = "shpaddactivex"
>	Width = 100
>
>
>	PROCEDURE activate_control
>		LOCAL loCtrl, loParent
>		loParent = this.parent
>		loParent.NewObject(this.cControlName,this.cClass,this.cClassLib)
>		loCtrl = EVALUATE("loParent." + this.cControlName)
>		loCtrl.left = this.left
>		loCtrl.width = this.Width
>		loCtrl.top = this.top
>		loCtrl.height = this.Height
>		loCtrl.visible = .T.
>		this.Visible = .F.
>	ENDPROC
>
>
>	PROCEDURE Init
>		LOCAL lcObjPath
>		lcObjPath = SYS(1272,THIS)
>		lcFormName = GETWORDNUM(lcObjPath,1,".")
>		lcObjPath = STUFF(lcObjPath,1,LEN(lcFormName),"")
>		IF VARTYPE(THISFORM.cPostActivateCmd) # "U"
>			THISFORM.cPostActivateCmd = THISFORM.cPostActivateCmd + CHR(13) + ;
>				"_vfp.forms('" + lcFormName + "')" + lcObjPath + ".activate_control()"
>		ENDIF
>	ENDPROC
>
>
>ENDDEFINE
>*
>*-- EndDefine: shpaddactivex
>**************************************************
>

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