Not necessarily. You Access the object in the Init so theoretically, oDom could be created in the Init. When you subsequently access the oXML.oDOM object later in code, it exists because it was already created.

It only has to hit that code once. In the Init, it fires at least twice (within the VFP engine).

>>>>Erik, that's cool!!
>>>>
>>>>Here is my analysis what's going on if you run it, obtained with good old SET DOHISTORY ON. :) And my comments just to clarify the sequence for myself in the first place. :)
>>>
>>>Yeah, gets kind of confusing if you think about it too much.
>>>
>>>In my book, THIS_Access has taken the place of COMPILE at runtime as the trippiest VFP feature.
>>>
>>>Note- this works over COM as well- your wrapper can be its own COM object, but it will not be early bindable...
>>
>>Erik,
>>Does _Access really work over COM? I know _Assign doesn't so I assumed (didn't want to put in the time to test *s*) _Access was the same.
>
>Hmm good question. Prior to your posting, I had only tested with a VFP client calling the COM object, and it works like a charm.
>
>But I just tested from VB, and on the PEMs that aren't defined in the typelib, it chokes with "Property not defined". I guess this is kind of telling about the difference in how VB and VFP call COM objects.
>
>Note that the Access method _is_ running. For example, I can instanciate the wrapper as a COM object and immediately check the value of oXML.oDOM.Async, and it says 'true'. If the oDOM_Access was not running, I would have gotten "oDOM is not an object".