Followup:

I got lucky, and my first hunch payed off in debugging this problem. I was obtaining the IE object ref in a local variable in my loop. After checking the IE object's path, the loop continues, eventually assigning another IE object reference (in fact the same one) to the same local variable. Now get this: I tried inserting a step that explicitly assigns NULL to this local IEobj variable right after using it, before the next loop cycle. I never thought such a step was necessary, because the assignment of a new reference implicitly frees the old one. Or so I thought... Sure seems to be a VFP bug, if I understand the rules correctly. Anyway this fixed the problem completely!

Now I shall celebrate by going to bed early.

>(snip)
>>Yes I am using the following; SHDocVw.ShellWindows and SHDocVw.InternetExplorer. It just seems that they are not always dependable. I was hoping there was a .NET framework way to do it that would be more bullet-resistant ;}
>>
>
>Joe,
>
>Sounds like we're talking about the same thing in two different languages. I'm curious how you've found it to be undependable, because at this moment I'm debugging some flaky C5 errors in a loop that repeatedly traverses the collection of Explorer windows, waiting to detect a certain path. Specifically, the line that bombs is:
>
>

>shellwpath = m.IEobj_arg.document.folder.self.path
>

>
>where I know that m.IEobj_arg is a valid reference to a Shell Explorer window with a well-defined path. The error doesn't occur on the first execution, but soon into a loop that runs the same statement against the same IE object. Even if I use type() to validate the expression, it bombs with a C5. My suspicion is that this may have something to do with how long one can safely hold on to and reuse various types of COM object references, even though they still should be valid, but this is just a preliminary guess.
>
>If you know of any specific Shell.Application problems or have any tips about using it, I'd be interested to hear them.
>
>Mike