nobody knows? :(

If you we're going the other way (using a VC++ .DLL in C#), it would be simple. But using a C#, or any other managed language, you have to go through COM to bridge between the two execution enviornments. RageInTheMachine9532 "...a pungent, ghastly, stinky piece of cheese!" -- The Roaming Gnome

Thanks.

You don't need to. You can use the System.Guid class. Charlie if(!curlies){ return; }

You don't - strings are wide characters (Unicode) by default in .NET. You actually have to convert to ANSI when calling native functions on Windows (as opposed to Windows NT). We have convered this countless times in the past, so I urge you both now and in the future to search first for previous similar questions. You can search this forum by clicking "Search comments" above. For an introduction to marshaling strings with Platform Invoke (P/Invoke), read Marshaling Strings[^]. Basically, when you use the DllImportAttribute to P/Invoke native DLL entry points, or define a structure for use with a native function using the StructLayoutAttribute, you set the CharSet field that both have to CharSet.Ansi (default for P/Invoke) to call only ANSI functions (where native strings are declared as char*), CharSet.Unicode to call only Unicode functions (where native strings are declared as wchar_t*, almost always the case for OLE/COM), or CharSet.Auto when you want to call ANSI functions in Windows (i.e., Windows 9x/ME) and Unicode functions in Windows NT (i.e., Windows NT 4, Windows 2000, Windows XP, Windows 2003, and "Longhorn", plus all future Windows platforms). Windows only supports ANSI (although there is a Unicode layer, but that's an extra install) and Windows NT typically supports both but it's better to use Unicode because it allows for a much larger character set and you don't have to mess with codepages. This posting is provided "AS IS" with no warranties, and confers no rights. Software Design Engineer Developer Division Sustained Engineering Microsoft [My Articles]

Since the function is defined externally, you have to modify it as such, and all P/Invoke functions are static (i.e., they aren't defined by a class). Your signature should look like this: [DllImport("user.dll", CharSet=CharSet.Unicode)] extern static int LoginDlg( int lDSType, string lptstrDataSource, int lDSLength, string lpctstrUsername, string lpctstrPassword); Drop the comma after lpctstrPassowrd and add a semi-colon after the declaration, as well. BTW, since the parameter names begin with either lp**t**str or lpc**t**str, they are most likely using platform-dependent string encodings. You best check your API documentation and thoroughly examine your headers. Using "t" typically means that a string is platform dependent, although thiscould be just a different naming convention for your APIs. If these are Microsoft APIs, I assure you they're platform-dependent strings and you should use CharSet.Auto. This posting is provided "AS IS" with no warranties, and confers no rights. Software Design Engineer Developer Division Sustained Engineering Microsoft [My Articles]

I've been using string almost every time without problem, and so does Microsoft most of the time in the Framework Class Library (FCL) for various native API P/Invoke declarations and struct fields. It wouldn't hurt to use a StringBuilder instead, but so long as you take care of allocating and freeing your strings appropriately (when necessary), you probably should be fine. Microsoft MVP, Visual C# My Articles

Try this: void Foo(ref object boolean) { if (boolean == null) //blah blah else { bool value = (bool) boolean; } } top secret

IntPtr Microsoft MVP, Visual C# My Articles

Thank you very much! It works prefectly now.

The .NET tab lists .NET Assemblies. When you click the Browse... button, you must pick a .NET assembly which uses the same extension. These contain a different PE/COFF header bit and different executable segments. If you want a shell extension that visual identifies .NET Assemblies (only .dlls, though, but those are all you can reference using VS.NET) by using an overlay icon, download and install my Shell Extensions for .NET Assemblies[^]. The COM tab lists COM controls (ActiveX controls) and COM typelibs (design-time discovery information, which VB6 and below uses as well). When you click the Browse... button, you must pick a DLL or OCX that contains COM information. The Projects tab lists other projects in your solution. Use this when developing a multi-project solution to keep assembly references in sync with the current build configuration. You should read some books on .NET development. These concepts are necessary to understand if you want to start writing anything other than "Hello, world" applications. Microsoft MVP, Visual C# My Articles

Seems that your dll is delivering strings. If you want to get a string from a dll, you should use a string builder. Try something like this: StringBuilder sb = new StringBuilder( 256 ); [DllImport( "myDll.dll" )] public static extern void GetString( StringBuilder sb ); void myFunc() { GetString( sb ); Debug.WriteLine( "String = " + sb.ToString() ); }

You should search for _Wildcard Charactersv_in its help. Mazy "Man is different from animals in that he speculates, a high risk activity." - Edward Hoagland

Yes, I did. It works very well. But I just wonder why my way doesn't work.

Thanks a lot!

Because of the fundamental architecture of COM and .NET interoperability. The code you're doing is essentially what the VB virtual machine does in the background using the IDispatch implementation of automation classes (it finds the method by the DISPID and invokes it with the specified parameters). You shouldn't have to do this, though. If you create your interop assembly correctly, you just use the classes and methods from that. That's what the interop assembly is for - wrapping the COM control in a runtime-callable wrapper (RCW). Again, read that link about exposing COM components to the .NET Framework I posted before. It's important to truly understand and not just accept the first thing that works. If you keep doing what you're doing, it'll take you forever to finish! Do it right and create and use the interop assembly. Microsoft MVP, Visual C# My Articles

Assuming you already looked under the "COM" tab of the add reference dialog box, the Component name used when creating a late bound control in VB6 using CreateObject often differs from the name displayed in the add reference dialog box. As an example, to create an Excel application reference in VB6, you could do this: xl = CreateObject("Excel.Application") but when you look in the VS.NET add reference dialog box, it is described as the "Microsoft Excel 9.0 Object Library". What a piece of work is man, how noble in reason, how infinite in faculties, in form and moving how express and admirable . . . and yet to me, what is this quintessence of dust? -- Hamlet, Act II, Scene ii.