>>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.

I meant to test this on XP over the holiday, but never got to it. I should note that the above behavior applies to Win2K SP4. I'll try to get to this tonight.