just create a file with number like file1.txt,file2.txt ..... file20.txt. after that, check like this, for (int i=0;i<20;i++) { CString str; str.Format(\_T("file%d"),i); if(!PathFileExists(str)) break; DeleteFile(str); } if file doesn't exists then break the loop. Regards, Srinivas

Cool. That's what I was looking for originally. But the memcpy works. THANKS!

ChemmieBro wrote: need to cast a cli array of unsigned char into unsigned char * Right. You don't cast, you marshal data from managed to unmanaged. Marshal::Copy Method[^] You can also pin a pointer to the first element of the array Direct manipulation of CLI arrays using native pointers[^] Mark Mark Salsbery Microsoft MVP - Visual C++ :java:

Another way is... int nNum = 10; char Data[4] = {0}; memcpy(&Data, &nNum, 4);

Yes. Lose the DllMain. Create a object dervied from CWinApp, declare global instance of it. Whatever was done in DLL_PROCESS_ATTACH, do it in CWinApp::InitInstance Whatever was done in DLL_PROCESS_DETACH do it in CWinApp::ExitInstance. Link with appropriate MFC library (static or dynamic). There may be a few other compiler or linker settings to tweak, but that is the gist of it.

You need to convert the decimal values back to ascii characters. Here is a code snippet =Encoding.ASCII.GetString(ArrayOfBytes,0,ArrayOfBytes.Length); this returns a ascii encoded string

Hello w_logan, >> So does this works for enum also? Yes. It works also for enum. The following is an example of how to define an automation-compatible enum in IDL : typedef [uuid(B5051CD9-A577-451b-BDD8-17AC68ED27BB)] enum { enum_value_0 = 0, enum_value_1 = 1, enum_value_2 = 2, enum_value_3 = 3 } EnumValue; Yes, the "typedef" keyword and the "uuid" attribute is necessary for proper definition of the enum type so that it is automation-compatible. Thereafter, you may include EnumValue as a type that can be used in your automation-compatible struct, e.g. : typedef [ uuid(1F2AFC9C-2ACB-4fc3-A415-8E0736B3C4BB), version(1.0), helpstring("My_Struct_VB_2") ] struct My_Struct_VB_2 // Example Struct { [helpstring("index.")] int index1; [helpstring("The Image_Struct struct.")] Image_Struct Image_List; [helpstring("EnumValue value.")] EnumValue ev1; } My_Struct_VB_2; >> can other languages using my DLL be able to use this struct. Because I was hoping my COM DLL will works with as my languages as possible and not just VB only. This very much depends on the language's IDE. VB and the Visual C# IDE do support most if not all of the automation-compatible IDL constructs. I haven't used Delphi or the other language IDEs yet so I wouldn't be able to comment on those. Send me an email and I can send you my sample program. Best Regards, Bio.

Thank you so much. It was a pretty simple fix using the _bstr_t class instead of the BSTR. My inexperience with BSTR and _bstr_t got the best of me. I don't know why I chose BSTR in my map instead of _bstr_t. But everything is working fine now!

My COM object is a singleton. Only one instance. The Public writing is fine as I already had that working properly. The Private is the functionality I am adding. Basically, if BOB calls LogEntry(private) then it needs to open BOB.txt on the first instance and log to BOB.txt every time after that. If TOM calls LogEntry(private) then it needs to open TOM.txt on the first instance and log to TOM.txt every time after that. ...and so on.

I think you might be surprised if you take a 'generic' C app and build it in windows and then trace through the 'standard C function' calls. You will find many of them devolving into regular WIN32 API calls. People were trying to convince me one time that the File* functions (fopen, close, fprintf, etc.) were faster than CreateFile WriteFile, ReadFile, etc. I traced into the C runtime and find that after a lot of variable hashing and flags manipulation, they end up calling the Win32 API anyway, so I just started calling the Win32 API directly, as there is no effort at being 'port ready' to other platforms for our products. I am not surprised that _access calls GetFileAttributes.

open ur stdAfx.h and #include "afx.h" after following line there. // TODO: reference additional headers your program requires here suhredayan There is no spoon.

ChemmieBro wrote: Well, I know it will be under either C:\Program Files or D:\Program Files or any other drive. Try this for starters. "Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow