Re: problems with passing arguments to an interface
"Rohit Kumar" <RohitKumar@discussions.microsoft.com> wrote in message
news:A1A46FA8-BA05-4FEB-A559-C5E3742734A6@microsoft.com
interface IWebLinkHelper : IDispatch{
[id(1), helpstring("method AddDownloadJob")] HRESULT
AddDownloadJob([in] CHAR* updateUrl, [in] CHAR* destUrl);
[id(2), helpstring("method DownloadUpdates")] HRESULT
DownloadUpdates([in] TCHAR* res);
It is a very bad idea to use TCHAR in a COM interface. Method signature
will change depending on whether you compile with or without Unicode,
but COM interface is supposed to be immutable at the binary level.
Imagine what happens when a client compiled as ANSI tries to call the
method on a component compiled as Unicode, and vice versa.
Decide whether you want narrow or wide characters after all, explicitly
use CHAR or WCHAR.
But when i call this method from my client
hr = WebLinkHelper->AddDownloadJob("C:\\main.asp","C:\\main1.asp");
the char* variables updateUrl & destUrl does not contain the correct
values. Please advice where i have went wrong.
Is it an out-of-proc component, by any chance? The way your method is
declared in IDL, it states that, for example, updateUrl is a pointer to
exactly one CHAR value. So the marshaller is going to marshal just the
first byte of the string. The rest is whatever garbage happens to be in
memory.
Since you want your interface to be automation compatible (that's why
you derived it from IDispatch and marked dual, right?), declare it like
this:
[id(1), helpstring("method AddDownloadJob")]
HRESULT AddDownloadJob([in] BSTR updateUrl, [in] BSTR destUrl);
BSTR is an automation type for strings.
--
With best wishes,
Igor Tandetnik
With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea. It is hard to be sure where they are going to
land, and it could be dangerous sitting under them as they fly
overhead. -- RFC 1925