George,
The project wasn't really converted. It's been rebuilt several times from scratch. When it was rebuilt, the project drew in the SPR files that were called but assigned a file type of 'E'. The problem I see (and Jonathan's response helped in this respect) is that VFP is looking at the type when it opens the project file and does not create a file object for those items.

Separate but included in this is any of the Query... events of the projecthook class expects an object variable as the first parameter. If you have code in one of those (e.g. QueryModifyFile) and attempt to modify one of the SPR files, VFP throws a 'Data type mismatch" error because oFile is a logical.

My contention is if its in the project file, the Files collection should have a reference to it. How big a deal could it be? Everything works normally except for the Project COM references.

>>Hi All,
>>The title spells it out but here is some more detail.
>>
>>I have an FPW project (yes, one of those) that was converted to VFP 3.0 then 6.0. However, not all of the code was converted. There is still extensive use of FPW SPR files. I have a project hook that runs through the Files collection and generates a report. The SPR files do not show up in the Files collection. Why not? The Files.Count property is off by the number of SPR files included in the project. They show up fine in the Project Manager itself, just not the COM collection.
>>
>>1. Has anyone noticed/experienced this before?
>>2. Is it a known bug? I checked on-line Technet but I might not have put in the correct keywords to get what I wanted.
>>3. If a bug, is there a workaround?
>>
>>Thanks for any information I can get.
>
>Larry,
>
>Don't forget that when you opened the project in VFP 6.0 (or previous version) it was converted to that format. If I had to hazard a SWAG, it would be that the sprs aren't recognized because VFP no longer uses that as the source of its screens/forms, but rather the scx and sct files that created them.