>Mark,
>
>First, I created the same files (in an empty directory) as you did. Second, I used the Windows Explorer to search for the file skeleton. It properly returned the expected result set. However, when I executed the code below, I got the same results as ADIR() showed.

LOCAL oFiles As Winfiles, cFileSkeleton, lncount
>SET PROCEDURE TO Winfiles additive
>oFiles = CREATEOBJECT('Winfiles')
>cFileSkeleton = '2003????.txt'
>lncount = 0
>IF oFiles.FindFile(cFileSkeleton) THEN
>  ? oFiles.cExtFileName
>  DO WHILE oFiles.FindNext()
>    ? oFiles.cExtFileName
>  ENDDO
>ENDIF

As you probably know, "Winfiles" is a custom class I created that uses the API calls FindFirstFile() and FindNextFile(). Further, if anyone else wants to run this test, the code is available from the download section under "Windows File Names".
>
>My conclusion therefore is that while the Windows Explorer may screen this type of result out, the underlying API calls do not. Therefore, I must conclude that this is an OS error.
>
>The question is, "Is this a significant enough problem to implement a fix in VFP?"

Good question. For me, knowing about the problem is good enough for now. I will add it to the UT Bug list for now. If the VFP Team picks it up, fine. Otherwise, no big deal for me.