Hello.Curtis.I am very interested in your project.I think that you can use the Webserices or .net remoting technology in you project. John

You could parse the filter into its individual patterns, sending each one to a separate thread. Each thread would then report back to the primary thread with its findings. Or, for each file on the target drive, see if it matches any of the patterns in the filter. I did this once back about 11 years ago. It was a DOS-based utility and was a very good learning exercise. "When I was born I was so surprised that I didn't talk for a year and a half." - Gracie Allen

Thanks for the info. I've done several services and a com+ service object. I'll check into using something like that.

This type of application is very typical of what people have been using Java to do. IBM's whole Linux push is based on Java applications.

Why did you use the ResourceManager? You simply grab the manifest resource stream. The ResourceManager is for ResX files. VS.NET has a great resource editor, far better than VS6. It still handles cursors, icons, and bitmaps internally. Instead of string resources, you're supposed to use ResX files. The great thing is that you can embed any file as an embedded resource. If you right-click, you can select "Open with..." to open ANY resource with ANY program (and keep a cached list of programs you use). In VS6, if the resource wasn't understood / handled by the IDE, you had to export the resource, browse to it and open it with the associated application (or open the application then open the file). That was a pain. In any case, 'tis far easier to just embed the .cur file as an embedded resource and use the Cursor constructor I mentioned, not the ResourceManager. Besides, binary files are stored as bse64 encodings by default. The ResourceManager has overhead for setting things up, then has to find the resource and decode it. The other way is quick and is closer to how it would be done in Win32 when loading a cursor from a persistent file. -----BEGIN GEEK CODE BLOCK----- Version: 3.21 GCS/G/MU d- s: a- C++++ UL@ P++(+++) L+(--) E--- W+++ N++ o+ K? w++++ O- M(+) V? PS-- PE Y++ PGP++ t++@ 5 X+++ R+@ tv+ b(-)>b++ DI++++ D+ G e++>+++ h---* r+++ y+++ -----END GEEK CODE BLOCK-----

"Oh My Fucking God" doesn't even come close!! That poor little sod! :eek: David Wulff Not all teenagers smoke and drink. I gave up smoking years ago.

Michael P Butler wrote: they show up late, other times they don't show at all :eek: Don't insult the hamsters! ;P ;P Paul ;) Tiny problem with said member has been corrected. Chris Maunder

I think the overflow was from lack of knowledge. From some ideas I got from leppie it has gone away. I removed the noentry option and the /clr option from the main project. I then did the /clr option individually for managed files and turned it off for nonmanaged files. It works much better now. I know I hade the __nogc* on my pointer to the managed string I sent in as a param. I don't think I had it on my pointer to a wchar_t block. I'll add that also as another precaution. For debuging I am still up in the air. I haven't gotten it to work in a real project when you mix managed and unmanaged. I have gotten it to work with a quick test project. I still might be wrong in the test project though. I created a .net console app. In the cpp file it gives you, I added a function called MyFunct() and put a pragma unmanaged before it. Then in the main function I called it. It stepped into it fine. Granted this isn't a dll like my other project and it is very simple. If I have time today, I will experiment some on it.

I eventually just made a wchar_t buffer of the right size and passed a pointer to it to the function. When it gets back it copies the buffer to the string like you had above. Works fine now. Thanks again. I'm going to pick up that book you mentioned soon.

I am not sure if you know that it is in fact locked by the OS (I assume you realy do not know). Try opening it with FILE_SHARE_READ. There are very few instances when you will be denied this access, the main reason is for security on WinNT/Win2000/WinxP. Of course if this is not a system level (kernal-level) file then there is a very good possiblity that the program that has it open is greedy and does not want to share reading privaliges why it has the file open. At the minimum, give Me/Us a code snippet of how you are atempting to open the file. Trust in the code Luke. Yea right!