Do you have an example of the second way?
I created a simple test solution to implement what I would think would be an
example of this "second way" proposed by Tim.
You can find it here (built using VS2008):
http://www.geocities.com/giovanni.dicanio/vc/TestInterop1.zip
In this sample solution, a DLL with a pure C native interface is built. This
DLL uses C++/CLI to call the managed C# class you proposed, and exports the
features of this class to the native world.
This DLL is lik a "bridge" between managed .NET platform and native
platform.
Then, a sample C++ native executable calls this DLL.
Lets say how should i edit the following code...
[...]
I dont know if it is even possible to export a struct that would hold
the results.
In the above solution, I just used a single string as output parameter, in
which the found drives were written, separated using ";" character.
This is some part of the C++/CLI code (this listing is the source code of
the C-interface function exported by the "bridging" DLL):
<code>
extern "C" NATIVEDRIVEENUM_API int __stdcall FindDrives(wchar_t *
listOfDrives, int maxChars)
{
//
// Check parameters
//
ATLASSERT(listOfDrives != NULL);
ATLASSERT(maxChars > 0);
//
// Call the C# class
//
DriveFinder^ driveFinder = gcnew DriveFinder();
array<String ^>^ drives = driveFinder->GetDrivesFound();
int count = drives->Length;
listOfDrives[0] = 0;
if (count == 0)
{
// Nothing found
return 0;
}
//
// Write output parameters
//
CString result;
result += CString(drives[0]);
for (int i = 1; i < count; i++)
{
result += L";";
result += CString(drives
);
}
StringCchCopyW( listOfDrives, maxChars, result );
return count;
}
</code>
HTH,
Giovanni