I'm currently using OleDbConnection/Adapter/Command/Reader, to get photo
search results I need in my application. It's working really well. Nice job
msft.

Unfortunately it doesn't look like there's a way to get those results
automatically updated once the contents of your HDD change. Can anyone
suggestion a solution here to know when I need to manually restart the
search? Or is there another way?

By the way, I was somewhat amazed to realize that if you use the Vista OS
search window, you run into the very same issue
1) Type jpg in Vista's search box
2) Note the filenames that show up in the search results4
3) copy over a new jpg on the machine
4) Note that the new jpg doesn't appear in the search list
5) The only way you can get it to show up, is to modify the search string
(for instance, hit backspace so that search string now just reads 'jp')

Try taking a look at System.IO.FileSystemWatcher.
Vista isn't using WPF for Explorer AFAIK, which could account for the lack
fo real-time updating of the search list. In WPF, if you were to create a
DataSourceProvider that fired DataChanged when a file changed, because of
the DependencyProperty system the UI will update without any coding on the
side of the consumer.

Thanks for the response Keith.

Just a bit confused by your post and talk of DataSourceProvider. Is there a
way to use Vista search as a DSP ? For now, I've assumed not.

Per your suggestions, I looked into using System.IO.FileSystemWatcher, but
in order for it to work, I need to watch all the user's HDD's (and watch for
removals/additions of drives), and either search for *.* or, add filters for
every file type that I'm interested in. I'd rather not hard code the filters
extensions because I want to make sure that as Vista adds support for
additional types. I'd much rather just say, watch for 'Photos' additions
removals - just like in the SQL query that I make.

I'm a missing something here? Or is it still a clunky solution? I'm scared
to find out what the overhead of watching all HDD for file
changes/adds/removes are, as opposed to letting the OS handle it in an
optimized way. I have it up and running, but for now, just do the entire SQL
query over again when a change is detected. Ugh.

Cheers

"Keith Patrick" wrote:

> Try taking a look at System.IO.FileSystemWatcher.
> Vista isn't using WPF for Explorer AFAIK, which could account for the lack
> fo real-time updating of the search list. In WPF, if you were to create a
> DataSourceProvider that fired DataChanged when a file changed, because of
> the DependencyProperty system the UI will update without any coding on the
> side of the consumer.
>
>
>
>

Sure, you can use virtually any data backend you want for the DSP as long as
you override the appropriate querying method(s). For Vista, search is going
to be in one of the internal APIs. Last I heard, Vista is using the
Indexing Service that's always been built into NT ("always" meaning as far
back as I remember; not necessarily back to 3.1) for its searching since
WinFS got pushed over to the SQL Server team, which is a shame because then
your Vista search API would just be another W*F. As it stands, I *think*
you can just treat the Indexing Service as a database, creating a
connectionstring for it and sending it SQL. See if this might help:
http://www.codeproject.com/aspnet/search.asp