odd results using Borland's FindFirst function

[Dangles]

After using Win7 for several months, suddenly getting odd file attribute values using FindFirst|FindNext VCL functions using Borland C++ Builder6 Enterprise.
The following code worked fine (for years in several versions of Windows)

TSearchRec sr;
int iAttributes = faDirectory;
if (FindFirst("*.*", iAttributes, sr) == 0)
{
if((sr.Name!=".") && (sr.Name!= ".."))
ListBox1->Items->Add(sr.Name);
while (FindNext(sr) == 0)
if((sr.Name!=".") && (sr.Name!= ".."))
ListBox1->Items->Add(sr.Name);
}
FindClose(sr);

This writes all directories within a selected directory to a listbox.
Only it doesnt do this all of a sudden.
TSearchRec.Attr has begun to return a value of 0x2010 regardless of whether the file pointed to is a directory or a hidden|system|Any file!

Which means my listbox is filled with every file|directory in the specified dir, and not just the intended directories.
Can anybody make sense out of this? Is this a virus? Or is it a Win7 "feature" that packs more values into a file attribute?

 

[Dangles]

since my post found a solution:
test TSearchRec.Attr with wanted attribute by and-ing them

if((sr.Attr & faDirectory) != 0)
{etc}

Like the Borland Help documentation says ...

"To test for an attribute, combine the value of the Attr field with the attribute constant with the and operator. If the file has that attribute, the result will be greater than 0. For example, if the found file is a hidden file, the following expression will evaluate to true: (SearchRec.Attr & faHidden) != 0."

It helps to read the manual sometimes! (But still cant figure why my abbreviated version worked for so many years - until it ran into Win7 - maybe to do with 64bit integers?)

You can all sleep peacefully now...