I'am a C# programmer, but I have problem with code in c++. Code in c++ (it is unamanaged provider for EBS for Sharepoint, if anyone is interested) calls c# function which is supposed to return string (actually, path of a file on disk), and in c++ that string should be converted in LPCTSTR. Which is the correct way of doing this, what type should be returned from c# to c++ and which type should be receieving type in c++ (I've tried std::string and LPWSTR, not working), and how to convert it then to LPCTSTR?
Here is the code that I've tried so far, and not working:
c++;
1 2 3 4 5 6 7 8 9 10 11 12 13 14
HRESULT hr = CoInitialize(NULL);
// Make a smart pointer to the IGetPathClass interface in DLL
IGetPathClassPtr pIGetPathClass(__uuidof(CGetPathClass));
// Return path using the ADD API
LPWSTR result;
hr = pIGetPathClass->GetPath(SiteID, FileID, &result);
// Release the COM interface
CoUninitialize();
wstring tTempStr;
tTempStr.assign(result.begin(), result.end());
LPCTSTR tPath = tTempStr.c_str();
c# (just returns string):
1 2 3 4 5 6 7 8 9 10 11
public interface IGetPathClass
{
string GetPath(Guid a, Guid b);
}
publicclass CGetPathClass : IGetPathClass
{
public string GetPath(Guid a, Guid b)
{
return"c:\\temp\\aaa";
}
}
I'm not sure how things are done in C# but in c++ when you declare that a member function takes two variables and returns a string it doesn't work to pass it three variables and cast the string that it returns to an HRESULT.
Take that tutorial and kill it with fire. I had to take a break from reading it after they referred to a function as an API, I couldn't even begin to understand the half assed hackish approach they are taking to accomplish a simple task like adding a custom class into a DLL. You will learn nothing useful from that site.
It's easy take line 8 in your code, append it to line 12 then delete "hr" and ", &result". Now tTempStr holds the string returned from your function. If your still having trouble copy paste your new code along with the error youre getting.
EDIT: I did a little more reading, just one more paragraph and I want to say there is no reason to register the dll, none what so ever.
It must be something to do with .Net then. I looked at the M$ article and I'd agree with you that this is the way they want you to call it but I can't make heads or tails of the " logic".