COM problem between Unmanaged C++ and Delphi - c++

I have a DLL in unmanaged C++ :
EditArticleManagerFactory.h:
class __declspec(dllexport) EditArticleManagerFactory : public NamedClassFactory<SCEditArticleManager>,
public SCBLEditArticle:ICOMEditArticleManagerFactory
{
public:
STDMETHODIMP CreateManager(BSTR bstrName, SCBLEditArticle::ICOMEditArticleManager** pEditArticleManager);
}
interface ICOMEditArticleManagerFactory : IUnknown
{
HRESULT CreateManager([in]BSTR bstrName, [out]ICOMEditArticleManager** pEditArticleManager);
}
EditArticleManagerFactory.cpp:
STDMETHODIMP EditArticleManagerFactory::CreateManager(BSTR bstrName, SCBLEditArticle::ICOMEditArticleManager** pEditArticleManager)
{
manager = factory->createManager(bstrName);
return manager->QueryInterface(__uuidof(SCBLEditArticle::ICOMEditArticleManager), (void**)&pEditArticleManager);
}
I'd like to call this method from Delphi and it should return an interface to a created manager.
Delphi:
function CreateManager(bstrName: wideString; pEditArticleManager: ICOMEditArticleManager): HResult; stdcall; external 'SCBLEditArticle.dll';
procedure CreateManager;
var
hr:HResult;
mCOMEditArticleManager: ICOMEditArticleManager;
begin
hr := CreateManager('MANAGER1', mCOMEditArticleManager);
end;
The problem is I get an access violation when it reaches the end; in this delphi method.
Do you have any ideea what could be wrong?
Thx, rufusz
Edit:
But I'm using a macro for implementing Release and
EditArticleManagerFactory.h :
IMPLEMENT_UNKNOWN_NODELETE(EditArticleManagerFactory) BEGIN_INTERFACE_TABLE(EditArticleManagerFactory) IMPLEMENTS_INTERFACE(SCBLEditArticle::ICOMEditArticleManagerFactory) END_INTERFACE_TABLE()
Inttable.cpp:
define IMPLEMENT_UNKNOWN_NODELETE(ClassName) \
STDMETHODIMP QueryInterface(REFIID riid, void **ppv) \ { \ HRESULT hr = InterfaceTableQueryInterface(this, GetInterfaceTable##ClassName(), riid, ppv);\ __if_exists(InheritedQueryInterface##ClassName) { if ( FAILED(hr) ) hr = InheritedQueryInterface##ClassName(riid, ppv); } \ return hr; \ }\ STDMETHODIMP_(ULONG) AddRef(void) { return 2; } \ STDMETHODIMP_(ULONG) Release(void) { return 1; }
Furthermore :
When I debug from Delphi, I get the access violation in the UnsetExceptionHandler
004046F7 3901 cmp [ecx],eax.
Maybe this can help to diagnose the problem.
Also if I declared an external function outside my C++ class, and called that from Delphi, I didn't get the access violation, but didn't get the interface pointer neither.
Also:
If I do nothing in the C++ method, I still get the AccessViolation.

Should be
function CreateManager(bstrName: wideString; OUT pEditArticleManager: ICOMEditArticleManager): HResult; stdcall; external 'SCBLEditArticle.dll';
Notice the "OUT", you somehow dropped a indirection. (an interface is only one *, not two)

It's odd you try to declare STDMETHODIMP CreateManager within your class in C++, this may be causing trouble.
Also COM provides a standard way of having an object-factory (class-object), which responds to CoCreateInstance calls, you may want to have a look at that.

Most likely there's something wrong with the reference counting.
When the function exists, the reference count to all interfaces is decremented. The Delphi compiler automatically creates the necessary code to call ICOMEditArticleManager::Release.
Either its implementation is flawed or you are not returning a valid IUnknown interface.
You can try the following:
In VC++ set a breakpoint at the implementation of ICOMEditArticleManager::Release
In Delphi switch to the CPU mode and single-step through the disassembled code.
That way you should find the cause or at least narrow it down.

Related

How to create a COM Dll in C++ that exposes a function which returns an object?

I am having a WCF (C# application) application that makes a call to a C++COM Dll. Now the method exposed by C++ COM dll has the following signature.
STDMETHODIMP MessageControl::CallMe(eEventType eventTypeVal, OUT long *pVal)
Now instead of returning a long *pVal I would like to return a interface which has multiple properties. Something like -
STDMETHODIMP MessageControl::CallMe(eEventType eventTypeVal, OUT IData *pVal)
So for the new interface how should I update the COM DLL? So Should I add a new entry in the IDL file for IData interface. I am new to this COM C++ Dll.
You need to have a function in your IDL like (assuming your interface is IMessageControl):
interface IMessageControl
{
STDMETHOD(CallMe)(eEventType eventTypeVal, [out,retval] IData** pVal);
}
or if you want option to return long or an object
interface IMessageControl
{
STDMETHOD(CallMe)(eEventType eventTypeVal, [out,retval] VARIANT* pVal);
}
Your C++ code would be something like:
STDMETHODIMP MessageControl::CallMe(eEventType eventTypeVal, IData** pVal)
{
return E_NOTIMPL;
}
or for variant version
STDMETHODIMP MessageControl::CallMe(eEventType eventTypeVal, VARIANT* pVal)
{
return E_NOTIMPL;
}
Obviously, once you implement, return S_OK for good return or an E_ type error code for a failure.

Getting Type Mismatch Error when calling CWnd::InvokeHelper

So I have tried to debug the program and as soon as I get into the Windows API function calls things get a little crazy, plus there isn't much help with debugging those files because I can't change them anyways. Basically what I am stuck on is the following two functions that I can change (FYI this is really old code and the program works in 32bit versions but when converted to 64bit this problem occurred):
void CSalvoPage::AdviseScrollingButtonPanel()
{
if ( m_SBPCookie == 0 )
{
IUnknown * pSinkUnk;
long * pCookie = &m_SBPCookie;
m_spSBPControlSink->QueryInterface(IID_IUnknown, (void **) &pSinkUnk);
if (pSinkUnk != NULL)
{
m_SalvoButtons.AddListener(pSinkUnk, pCookie);//here is the problem~~~~
pSinkUnk->Release();
}
}
}
Then we have the AddListener call which does this
void CNvButtonPanel::AddListener(LPUNKNOWN pUnk, long* pCookie)
{
static BYTE parms[] =
VTS_UNKNOWN VTS_PI4;
InvokeHelper(0x16, DISPATCH_METHOD, VT_EMPTY, NULL, parms,
pUnk, pCookie);
}
I know for a fact that the InvokeHelper function throws the exception through debugging. All I seem to understand is that parms[] lets the InvokeHelper know what types of parameters it's getting and how many. I looked up the definitions and found that in fact
VTS_UNKNOWN = "\x0D" //IUNKNOWN*
and
VTS_PI4 = "\x43" //a 'long*'
Therefore I am telling the InvokeHelper the correct types of parameters to expect so I don't understand why I get a Type Mismatch Error in a popup window everytime I run the program... Any ideas as to why my InvokeHelper throws the Type Mismatch Error?
I have tried to look into the InvokeHelper method documentation and it's really confusing... What I do know is that it throws the COleException mentioned in the documentation and the SCODE returned from the Invoke method is -2147352571
[id(22), helpstring("method AddListener")]
HRESULT AddListener(
[in] IUnknown * pUnk,
[out] IUnknown ** pCookie
);
I was able to fix the issue by doing what RbMm suggested which was to change the function AddListener and RemoveListener functions to match the types declared in the .idl file.
void AddListener(LPUNKNOWN pUnk, LPUNKNOWN* pCookie);
void RemoveListener(LPUNKNOWN pCookie);
The functions now correctly match the types defined in the .idl file
[id(22), helpstring("method AddListener")]
HRESULT AddListener(
[in] IUnknown * pUnk,
[out] IUnknown ** pCookie
);
[id(23), helpstring("method RemoveListener")]
HRESULT RemoveListener(
[in] IUnknown * pCookie
);

Delphi communication with C++ dll (parameters)

Hi I'm having quite some issues with integrating a DLL inside my Delphi 2007 application.
i suspect that I'm doing something wrong with the parameters of the calls.
At this moment i have 2 issues, but i think they are related to eachother.
1)
First call with the DLL:
from the .h file:
extern "C" {
__declspec(dllexport) HRESULT Startup(char* version);
}
This call should initialize the DLL and give me the version back of the DLL. HRESULT should be 0, and the version pointer should contain the version.
My Delphi code:
function Startup(var version: Pchar): HRESULT; cdecl; stdcall; external 'myDLL.dll';
And the actual call:
var
res : HRESULT;
Name1 : PChar;
test : AnsiString;
buf2: array [0..20] of AnsiChar;
begin
FillChar(buf2,20,0);
Name1:= #buf2[0];
res := RdmStartup(Name1);
//Here res = 0, but the Name1 stays empty, and the buf2 still contains 0.
end;
But as the result is 0 the call was a success.
Then my second issue: i need to call a function in the DLL that will open a COM port.
The .h:
extern "C" {
__declspec(dllexport) HRESULT Open(HWND hWnd, int Port, DWORD BaudRate, DWORD Interval);
}
And my Delphi declare:
function Open(hWnd: HWND;Port : integer;BaudRate:LongInt;Interval:LongInt): HRESULT; cdecl; stdcall; external 'myDLL.dll';
and i call this by:
res:= Open(self.Handle,5,115200,500);
And here i'm getting a failure back from the DLL in the res variable.
i also have the source of the DLL, and the failure that i'm getting is from the part where the DLL is checking if the parameters are valid, if they are valid it will continue, else return the error i'm currently getting.
The things it is checking:
if(hWnd == NULL)
{
return false;
}
if(BaudRate != 2400 && BaudRate != 9600 && BaudRate != 38400 && BaudRate != 115200)
{
return false;
}
if(IntervalTimer < 300)
{
return false;
}
std::string strPortName = lexical_cast<std::string>( format("COM%d") % Port);
std::string strPortName(lpPortName.c_str());
std::string::size_type loci = strPortName.find("COM");
if( loci == std::string::npos )
{
return false;
}
return true;
And one of these above is returning false on my call, because if the result of this function is false, the DLL gives the error i'm currently getting in the results.
Does anyone have an idea of what i am doing wrong?
i've tried numerous of combinations for the types in the end i sticked to the conversion i found at: http://www.drbob42.com/delphi/headconv.htm
i've also tried different ways of reading the char pointer, but all of them failed.....
So at this stage i know i am succesfully communicating with the DLL as i'm getting different HRESULTs back for the 2 calls, but i suspect my parameters are not working like the should.
I'm using Delphi 2007 and the C++ DLL was build with VS2010.
The declaration of Startup is pretty suspicious:
__declspec(dllexport) HRESULT Startup(char* version);
This translates into:
function Startup(version: PAnsiChar): HResult; stdcall; external 'myDLL.dll';
So there should be no var there.
I got from your comments that the cdecl calling convention works for some of your code. In that case remove stdcall, since it overrules the preceding cdecl.
The declaration of Open() seems to be pretty OK (I would use DWORD as type, not Longint, especially since DWORD is Longword these days -- but in Win32 they are the same size, so that won't make any big difference for you). And you seem to be passing the right parameters too.
You did not write what the HRESULT value is that you get back. But I assume that the port COM5 simply cannot be opened with these settings.
What can you do?
You should remove the var from Startup().
So you can try:
to use cdecl instead of stdcall (the stdcall in your declaration overrules the cdecl)
to open different COM ports with different parameters
to decode the HRESULT that is returned.
A better diagnosis is not possible, from a distance, without the same hardware and software, sorry.
You could read my article on conversion. This has also a few paragraphs that explain how to debug the code to find out the proper calling convention. It can probably help you with more of your problems converting headers, too.

Call Delphi CLASS exported in DLL from C++ code

i have a problem to use delphi class from C++ code. delphi dll demo that export a function that return an object.
my delphi Dll code is as follow:
library DelphiTest;
// uses part....
type
IMyObject = interface
procedure DoThis( n: Integer );
function DoThat : PWideChar;
end;
TMyObject = class(TInterfacedObject,IMyObject)
procedure DoThis( n: Integer );
function DoThat: PChar;
end;
// TMyObject implementation go here ...
procedure TMyObject.DoThis( n: Integer );
begin
showmessage('you are calling the DoThis methode with '+intToStr(n) +'parameter');
end;
function TMyObject.DoThat: PChar;
begin
showmessage('you are calling the DoThat function');
Result := Pchar('Hello im Dothat');
end;
// exporting DLL function :
function CreateMyObject : IMyObject; stdcall;export;
var
txt : TextFile;
begin
AssignFile(txt,'C:\log.log');
Reset(txt);
Writeln(txt,'hello');
Result := TMyObject.Create;
end;
exports CreateMyObject;
in my C++ project i declared the IMyObject interface as follow :
class IMyObject
{
public:
IMyObject();
virtual ~IMyObject();
virtual void DoThis(int n) = 0;
virtual char* DoThat() = 0;
};
and my main function as follow :
typedef IMyObject* (__stdcall *CreateFn)();
int main()
{
HMODULE hLib;
hLib = LoadLibrary(L"DelphiTest.dll");
assert(hLib != NULL); // pass !!
CreateFn pfnCreate;
pfnCreate = (CreateFn)GetProcAddress((HINSTANCE)hLib, "CreateMyObject");
if (pfnCreate == NULL)
{
DWORD errc = GetLastError();
printf("%u\n", errc); // it gets error 127
}
else{
printf("success load\n");
}
IMyObject* objptr = pfnCreate();
objptr->DoThis(5);
FreeLibrary(hLib);
int in;
scanf_s("%i", &in);
return 0;
}
with this example i got an error at run time when i try to access the exported function. the errors is at line :
IMyObject* objptr = pfnCreate();
can you tell me what is wrong about my example.
and if possible any working example to access Delphi class (in DLL) from C++ code.
The first problem is calling convention of the methods. The Delphi interface uses register which is a Delphi specific calling convention. Use stdcall, for example, for the methods of the interface.
The next problem is in the C++. Your C++ interface must derive from IUnknown. Further, it should not declare a constructor or destructor.
Beyond that your Delphi code exports PWideChar which does not map to char*. It maps to wchar_t*.
Looking further ahead, returning a PChar works fine here because your implementation returns a literal. But more serious code will want to use a dynamically allocated string presumably and at that point your design is flawed.
Do note that you need to be an elevate administrator to create a file at the root of the system drive. So that's yet another potential failure point.
I expect there are other mistakes, but that's all I've found so far.

What is the difference between COM property methods and regular interface methods?

I have been poking around with WRL at the ABI layer for the last couple of weeks and have run into this problem.
I have an interface defined in IDL as follows:
namespace Async{
[uuid(f469e110-7ef5-41df-a237-9ddef9aed55c), version(1.0)]
interface IDownloader : IInspectable
{
HRESULT GetFeed([in] HSTRING url,[out, retval] Windows.Web.Syndication.SyndicationFeed ** feed);
[propget]HRESULT Feed([out, retval]Windows.Web.Syndication.SyndicationFeed ** feed);
}
[version(1.0), activatable(1.0)]
runtimeclass Downloader
{
[default] interface IDownloader;
}
}
Which I have defined in my header file like so:
#pragma once
#include "Async_h.h"
namespace ABI {
namespace Async {
class Downloader : public Microsoft::WRL::RuntimeClass<ABI::Async::IDownloader>
{
InspectableClass(L"Async.Downloader", BaseTrust);
public:
Downloader();
STDMETHOD(GetFeed)(HSTRING url, ABI::Windows::Web::Syndication::ISyndicationFeed ** feed);
STDMETHOD(get_Feed)(ABI::Windows::Web::Syndication::ISyndicationFeed ** feed);
private:
//Microsoft::WRL::ComPtr<ABI::Windows::Foundation::Uri> feedUrl;
Microsoft::WRL::ComPtr<ABI::Windows::Web::Syndication::ISyndicationFeed> m_feed;
};
ActivatableClass(Downloader);
}
}
In my cpp file I implement the functions:
STDMETHODIMP Downloader::GetFeed(HSTRING url, ISyndicationFeed** feed)
{
HRESULT hr;
RoInitializeWrapper ro(RO_INIT_MULTITHREADED);
ComPtr<IUriRuntimeClass> uri;
ComPtr<IUriRuntimeClassFactory> uriFactory;
hr = GetActivationFactory(HStringReference(RuntimeClass_Windows_Foundation_Uri).Get(), &uriFactory);
hr = uriFactory->CreateUri(url, uri.GetAddressOf());
ComPtr<ISyndicationClient> client;
ComPtr<IInspectable> inspectable;
RoActivateInstance(HStringReference(RuntimeClass_Windows_Web_Syndication_SyndicationClient).Get(), &inspectable);
hr = inspectable.As(&client);
Event timerCompleted(CreateEventEx(nullptr, nullptr, CREATE_EVENT_MANUAL_RESET, WRITE_OWNER | EVENT_ALL_ACCESS));
auto callback = Callback<IAsyncOperationWithProgressCompletedHandler<SyndicationFeed*,RetrievalProgress>>([&](IAsyncOperationWithProgress<SyndicationFeed*,RetrievalProgress> *op, AsyncStatus status) ->HRESULT
{
auto error = GetLastError();
if (status == AsyncStatus::Completed)
{
hr = op->GetResults(m_feed.GetAddressOf());
*feed = m_feed.Get();
}
return S_OK;
});
ComPtr<IAsyncOperationWithProgress<SyndicationFeed*,RetrievalProgress>> operation;
hr = client->RetrieveFeedAsync(uri.Get(), operation.GetAddressOf());
operation->put_Completed(callback.Get());
return S_OK;
}
STDMETHODIMP Downloader::get_Feed(ISyndicationFeed** feed)
{
*feed = m_feed.Get();
return S_OK;
}
The property works as expected it is projected to c++/cx as it should be. However,in the GetFeed method, when I attempt to set the feed parameter to the retrieved feed I get an access violation. Obviously I know that the memory is bad but the way I understand COM properties, they are essentially function calls and the property method and the GetFeed method are doing exactly the same thing minus the retrieval part.
Here are my questions:
What is the difference between COM property methods and regular interface methods in terms of the projected return value if any?
Why is the parameter to the property method initialized to nullptr and the parameter to the GetFeed Method not when they are described exactly the same in IDL?
If the out parameters in property methods are initialized, what part of the COM runtime is doing that for me and is that controllable? IE is there a way to get memory that I can write to passed to me?
I know that I could probably design that away but that is not the point. I am just trying to learn how it all works.
Thanks.
In your lambda you are capturing by reference with [&]. You need to capture the feed parameter by value, since the stack frame is long gone by the time your lambda executes.
The bigger issue is that the client has no idea when they can retrieve the results since you don't provide that information. (I see you create an unused Win32 Event object, so maybe there's some other code to make that work that you've deleted).