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.